|
Es un hecho de
todos conocido que Internet constituye un canal de comunicaciones inseguro,
debido a que la información que circula a través de esta red es fácilmente
accesible en cualquier punto intermedio por un posible atacante. Los datos
transmitidos entre dos nodos de Internet (por ejemplo su máquina y el servidor
Web desde el que quiere descargar una página) se segmentan en pequeños paquetes
que son encaminados a través de un número variable de nodos intermedios hasta
que alcanzan su destino. En cualquiera de ellos es posible leer el contenido de
los paquetes, destruirlo e incluso modificarlo, posibilitando todo tipo de
ataques contra la confidencialidad y la integridad de sus datos. En Internet, la solución más comúnmente
adoptada para construir el análogo digital de este sobre se basa en la
utilización del protocolo SSL.
Qué es SSL
SSL (Secure Sockets Layer) fue diseñado y propuesto en 1994 por Netscape
Communications Corporation junto con su primera versión del Navigator como un
protocolo para dotar de seguridad a las sesiones de navegación a través de
Internet. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0
que alcanzó su madurez, superando los problemas de seguridad y las limitaciones
de sus predecesores. En su estado actual proporciona los siguientes servicios:
Cifrado de datos: la información transferida, aunque caiga en manos de un
atacante, será indescifrable, garantizando así la confidencialidad.
Autenticación de servidores: el usuario puede asegurarse de la identidad del
servidor al que se conecta y al que posiblemente envíe información personal
confidencial.
Integridad de mensajes: se impide que modificaciones intencionadas o
accidentales en la información mientras viaja por Internet pasen inadvertidas.
Opcionalmente, autenticación de cliente: permite al servidor conocer la
identidad del usuario, con el fin de decidir si puede acceder a ciertas áreas
protegidas.
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.).
SSL proporciona sus servicios de seguridad sirviéndose de dos tecnologías de
cifrado distintas: criptografía de clave pública (asimétrica) y criptografía de
clave secreta (simétrica). Para el intercambio de los datos entre el servidor y
el cliente, utiliza algoritmos de cifrado simétrico, que pueden elegirse
típicamente entre DES, triple-DES, RC2, RC4 o IDEA. Para la autenticación y para
el cifrando de la clave de sesión utilizada por los algoritmos anteriores, usa
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 del y van al servidor una
vez establecido el canal 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 los mensajes de futuras transacciones. Por su parte, 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.
Cómo funciona SSL
Cuando un navegador solicita una página a un servidor seguro, ambos 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 garantizar la confidencialidad e integridad y para la autenticación mutua.
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 producció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 mediante el 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. Más adelante, ambos generarán idénticas claves de sesión a partir de la
clave maestra generada por el navegador.
4. 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, 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 siguiente
información:
El URL del documento solicitado.
Los contenidos del documento solicitado.
Los contenidos de cualquier formulario enviado desde el navegador.
Las cookies enviadas desde el navegador al servidor y viceversa.
Los contenidos de las cabeceras HTTP.
Limitaciones y problemas
Debido a ciertas limitación de exportación de algunos paises sobre
los productos criptográficos, las versiones de los navegadores distribuidas
legalmente más allá de sus fronteras operan con nada más que 40 bits de longitud
de clave, frente a los 128 ó 256 bits de las versiones fuertes. Claves tan
cortas facilitan los ataques de fuerza bruta por búsqueda exhaustiva de claves,
pudiéndose descifrar mensajes cifrados en estas condiciones tan desfavorables en
cuestión de horas o días, dependiendo de los recursos informáticos disponibles.
Este serio problema ganó notoriedad en los medios de comunicación, por ejemplo
en 1995
un estudiante francés, Damien Doligez, fue capaz de descifrar un mensaje cifrado
con SSL en pocos días utilizando la red de ordenadores de su Universidad. Aun
hoy, sin importar lo sofisticado y seguro que sea SSL v3.0, mientras se
mantengan las restricciones de exportación y los usuarios españoles adquieran
navegadores de claves cortas, la falta de seguridad está garantizada.
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 número de tarjeta de crédito, número de
la seguridad social, 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. Por otro lado, debe tenerse muy en cuenta que
SSL no garantiza la identidad del servidor al que se conecta el usuario. Muy
bien podría suceder que el servidor seguro contase con un certificado
perfectamente válido y que estuviera suplantando la identidad de algún otro
servidor seguro bien conocido, como el de Amazon. Por consiguiente, es de
extrema importancia que se compruebe siempre el certificado del sitio Web para
cerciorarse de que no se está conectando a un Web falsificado.
El servidor identifica al navegador incluso aunque éste no se autentique
mediante certificados. Cuando un usuario se conecta a un servidor,
rutinariamente le comunica ciertos datos como su dirección IP, tipo y versión de
navegador y sistema operativo, y otros más. Con esta información es posible,
según los casos, llegar directamente hasta el individuo, o al menos compañía,
que se conectó al servidor. El mero hecho de utilizar un canal cifrado con SSL
no elimina este traspaso de información desde el navegador al servidor.
Por último, actualmente SSL solamente se utiliza para comunicaciones seguras en
WWW, por lo que otros servicios de Internet, como el correo electrónico, no irán
cifrados a pesar de utilizar SSL para el envío de formularios o la recuperación
de páginas Web. Recuerde, debe usar S/MIME, PGP o algún otro software
criptográfico para correo, ya que SSL no ofrece protección para sus mensajes.
Ventajas de SSL
- SSL v3.0 goza de gran popularidad y se eeencuentra ampliamente extendido en
Internet, ya que viene soportado por los dos principales navegadores del
mercado, Netscape Navigator 3.0 ó superior así como por Internet Explorer 3.0 ó
superior.
- SSL proporciona un canal de comunicacionnnes seguro entre los servidores Web y
los clientes (los navegadores), pero su uso no se limita a la transmisión de
páginas Web. Al encontrarse entre los niveles de transporte y de aplicación,
potencialmente SSL puede servir para securizar otros servicios, como FTP,
correo, telnet, etc.
- El usuario no 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.
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 en España 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 españoles, 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:
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.
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
inadecuadamente, 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.
|