fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su madurez, superando los problemas de seguridad y limitaciones de sus predecesores. En su estado actual, proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y, opcionalmente, autenticación de cliente para conexiones TCP/IP.
SSL v3.0 goza de gran popularidad, por lo que se encuentra ampliamente extendido en Internet. Viene soportado por los dos principales navegadores del mercado, Netscape Navigator 3.0 ó superior, así como por Internet Explorer 3.0 ó superior.
No se necesita realizar ninguna acción especial para invocar el protocolo SSL, basta con seguir un enlace o abrir una página cuya dirección empieza por https://. El navegador se encarga del resto.
1.12.6.1 ¿Cómo funciona SSL? El rasgo que distingue a SSL de otros protocolos para comunicaciones seguras, como el hoy prácticamente extinto S-HTTP, es que se ubica en la pila OSI entre los niveles de transporte (TCP/IP) y de aplicación (donde se encuentran los conocidos protocolos HTTP para Web, FTP para transferencia de ficheros, SMTP para correo electrónico, Telnet para conexión a máquinas remotas, etc.). Gracias a esta característica, SSL resulta muy flexible, ya que puede servir para seguridad potencialmente otros servicios además de HTTP para Web, sin más que hacer pequeñas modificaciones en el programa que utilice el protocolo de transporte de datos TCP.
SSL proporciona sus servicios de seguridad cifrando los datos intercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico, que puede elegirse entre DES, triple-DES, RC2, RC4 o IDEA, y cifrando la clave de sesión de los algoritmos anteriores mediante un algoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que se utiliza para cifrar los datos que vienen y van al servidor seguro. Se genera una clave de sesión distinta para cada transacción, lo cual permite que aunque sea reventada por un atacante en una transacción dada, no sirva para descifrar futuras transacciones.
MD5 o SHA se pueden usar como algoritmos de resumen digital (hash). Esta posibilidad de elegir entre tan amplia variedad de algoritmos dota a SSL de una gran flexibilidad criptográfica.
Durante el protocolo SSL, el cliente y el servidor intercambian una serie de mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes fases (de manera muy resumida):
1. La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos para mantener la intimidad y para la autenticación. El navegador le informa al servidor de los algoritmos que posee disponibles. Normalmente se utilizarán los más fuertes que se puedan acordar entre las dos partes. En función de las posibilidades criptográficas del navegador, el servidor elegirá un conjunto u otro de algoritmos con una cierta longitud de claves.
2. La fase de autenticación, en la que el servidor envía al navegador su certificado x.509v3 que contiene su clave pública y solicita a su vez al cliente su certificado X.509v3 (sólo si la aplicación exige la autenticación de cliente).
3. La fase de creación de clave de sesión, en la que el cliente envía al servidor una clave maestra a partir de la cual se generará la clave de sesión para cifrar los datos intercambiados posteriormente haciendo uso del algoritmo de cifrado simétrico acordado en la fase 1. El navegador envía cifrada esta clave maestra usando la clave pública del servidor que extrajo de su certificado en la fase 2. Posteriormente, ambos generarán idénticas claves de sesión a partir de la clave maestra generada por el navegador.
4. Por último, la fase Fin, en la que se verifica mutuamente la autenticidad de las partes implicadas y que el canal seguro ha sido correctamente establecido. Una vez finalizada esta fase, ya se puede comenzar la sesión segura.
De ahí en adelante, durante la sesión segura abierta, SSL proporciona un canal de comunicaciones seguro entre los servidores Web y los clientes (los navegadores) a través del cual se intercambiará cifrada la información relevante, como el URL y los contenidos del documento solicitado, los contenidos de cualquier formulario enviado desde el navegador, las cookies enviadas desde el navegador al servidor y viceversa y los contenidos de las cabeceras HTTP. [8]
1.12.6.2 Uso de SSL en comercio electrónico. SSL constituye la solución de seguridad implantada en la mayoría de los servidores web que ofrecen servicios de comercio electrónico. Su mayor mérito radica en ofrecer respuesta al principal problema que afronta el comercio en línea: la renuencia de los usuarios a enviar su número de tarjeta de crédito a través de un formulario web por el temor de que caiga en manos de un hacker y por la desconfianza generalizada hacia Internet, a lo que se suma la falta de costumbre de compra por catálogo.
La forma más fácil y más extendida para construir un sistema de comercio en Internet consiste en utilizar un servidor web con un catálogo con información sobre los productos o servicios ofrecidos y un formulario para procesar los pedidos. El catálogo estará compuesto por una serie de páginas web describiendo la mercancía en venta, acompañadas de imágenes, dibujos, especificaciones, animaciones, clips de vídeo o audio, applets de Java, controles ActiveX, etc. Estas páginas web se pueden crear estáticamente con un programa de edición HTML como Microsoft FrontPage o Adobe PageMill, o también pueden crearse dinámicamente desde una base de datos de los artículos y su información asociada, con programas como FileMaker Pro de Claris. Junto a cada artículo se sitúa un botón que el usuario puede pulsar para comprarlo o, más comúnmente, para añadirlo al carrito de la compra para pagarlo todo al final. Cuando el cliente ha terminado sus compras, pasa por una "caja virtual", que iniciará el proceso de pago.
Hoy por hoy, el medio de pago más común en Internet es la tarjeta de crédito. No obstante, no hay que despreciar otros métodos más conservadores, aunque a menudo preferidos por los compradores, como el envío contra reembolso o la transferencia bancaria, que representan un porcentaje importante de las ventas en línea.
El usuario debe rellenar un formulario con sus datos personales (tanto para el caso del envío de los bienes comprados, como para comprobar la veracidad de la información de pago), y los datos correspondientes a su tarjeta de crédito (número, fecha de caducidad, titular).
Esta arquitectura no exige que el servidor disponga de capacidades especiales para el comercio. Basta con que se utilice como mínimo un canal seguro para transmitir la información de pago y el comerciante ya se ocupará manualmente de gestionar con su banco las compras.
Sin embargo, este enfoque, aunque práctico y fácil de implantar, no ofrece una solución comercialmente integrada ni totalmente segura A medida que el comercio crece, esta arquitectura podría llegar a resultar difícil de expandir o de incorporar nuevas tecnologías y componentes a medida que vayan apareciendo. Existen una serie de desventajas al utilizar exclusivamente SSL para llevar adelante ventas por Internet:
Por un lado, SSL ofrece un canal seguro para el envío de números de tarjeta de crédito, pero carece de capacidad para completar el resto del proceso comercial: verificar la validez del número de tarjeta recibido, autorizar la transacción con el banco del cliente, y procesar el resto de la operación con el banco adquiriente y emisor.
Por otro lado, es importante recalcar que SSL sólo garantiza la confidencialidad e integridad de los datos en tránsito, ni antes ni después. Por lo tanto, si se envían datos personales al servidor, entre ellos el ya citado número de tarjeta de crédito, el número de la seguridad social, el DNI, etc., SSL solamente asegura que mientras viajan desde el navegador hasta el servidor no serán modificados ni espiados. Lo que el servidor haga con ellos, está ya más allá de la competencia de este protocolo.
Los datos podrían ser manipulados irresponsablemente o caer en manos de un atacante que asaltara el servidor con éxito. Además, SSL permite realizar ataques sobre servidores de comercio creados chapuceramente, para averiguar números de tarjeta reales. Un programa escrito por el hacker va probando números de tarjeta válidos, pero que no se sabe si corresponden o no a cuentas reales, realizando compras ficticias en numerosos servidores. Si el número de tarjeta no sirve, el servidor devuelve un error, mientras que si es auténtico, el servidor lo acepta.
El programa entonces cancela la compra y registra el número averiguado, para seguir adelante con el proceso. De esta forma, el hacker puede hacerse en breve con cientos de números auténticos. Todos estos inconvenientes convierten a SSL en una solución deficiente desde el punto de vista del pago electrónico, lo cual no significa que no se deba utilizar ni que no sea útil en otras muchas facetas igualmente necesarias de la actividad empresarial.
Al proporcionar un canal seguro de comunicaciones, el comerciante puede ofrecer al cliente de manera confidencial una serie de servicios para estrechar las relaciones de confianza: autenticación del cliente frente al comercio, trato personalizado, evitar que terceras partes espíen las compras de los clientes, intercambio de información privada, etc. Dado que SSL es un protocolo seguro de propósito general, que no fue diseñado para el comercio en particular, se hace necesaria la existencia de un protocolo específico para el pago. Este protocolo existe y se conoce como SET. Además del cifrado de datos, el protocolo SSL proporciona:
Para que este protocolo sea empleado debe cumplir por lo menos varios de los requisitos básicos de seguridad como:
SSL se ha convertido rápidamente en Internet en el protocolo de seguridad más utilizado, además de ser un estándar y venir incluido por defecto en los navegadores Netscape Navigator e Internet Explorer. Lo que permite una implementación muy sencilla del sistema de pago ya que el cliente puede comenzar a comprar sin tener que realizar ningún proceso de autentificación previa.
Para crear un sistema de pago electrónico basado en SSL es necesario conseguir un certificado electrónico para el vendedor, generalmente se obtiene de la empresa Verisign (principal autoridad certificadora mundial y filial de RSA Data Security Inc.). Verisign está considerada por Microsoft y Netscape como CA de confianza por lo que por defecto viene activada en sus respectivos navegadores.
Una vez realizado el pago, el vendedor obtiene el PIN de la tarjeta de crédito del cliente, por lo que debe estar provisto de algún método que permita enviar estos datos a una entidad financiera que sea capaz de realizar la transferencia bancaria.
Por ejemplo, Banesto ha sido pionera en ofrecer un sistema completo de pago electrónico basado en SSL e incluso ha creado su propia tarjeta de crédito para este propósito, la Virtual C@sh. La comunicación entre el vendedor y Banesto se realiza a través de un protocolo privado.
Otra opción que han ofrecido varios bancos es la de utilizar un Terminal Punto de Venta o TPV para realizar la transferencia. Se conecta el TPV al servidor del vendedor y mediante un software CGI se realiza la comunicación.
Los servidores seguros SSL se podrán notar, porque en la esquina inferior izquierda cambia a un candado cerrado en el caso de Netscape. En el URL, cambia de Http:// a Https://. En la figura se observa como se realiza una implementación con el protocolo SSL
Figura. Implementación del Protocolo SSL.
El ataque es posible pero poco probable. La vulnerabilidad no produce sobre SSL, sino sobre PKCS (Public Key Crytography Standard) encargado del intercambio de llaves en SSL.
El ataque consiste en mandar mensajes cuidadosamente construidos contra el servidor seguro de tal forma que produzca mensajes de error de vuelta, a partir de cuya información se puede sacar la llave critica para seguridad. Se necesita alrededor de un millón de mensajes para esto, hecho que debería llamar la atención del administrador del sistema. [8]