Capa de sockets seguros (SSL)
La
seguridad (o la aparente carencia de seguridad, según el lado desde el que
miremos) es la barrera real y psicológica que es necesario franquear para el
definitivo despegue del comercio
electrónico. Los elementos que forman esta barrera son siete y van más allá de lo meramente físico
(hardware) o lógico (protocolos, aplicaciones) e involucran factores tales como
la legislación, la educación de los usuarios, etc. Estos siete elementos son:
- Confidencialidad.
- Integridad.
- Disponibilidad.
- No Repudio.
- Verificación de la Identidad.
- Validez Legal.
- Confianza de los Usuarios.
El protocolo dominante en la
actualidad en el panorama del comercio electrónico, proporciona
confidencialidad, integridad y verificación de la identidad de ambas partes (esta última característica sólo
si se utiliza en conjunción de certificados digitales en ambos extremos, cosa
que no suele ser frecuente). La disponibilidad es algo que se escapa del ámbito
del protocolo y que se ve gravemente
perjudicada por lo pesado del mismo (aunque existen soluciones hardware
integradas con él y diseñadas a tal
efecto que veremos en el capítulo 6 de este documento). La validez legal de una
transacción comercial a través de Internet es algo fuera del objeto de este documento y la confianza de los
usuarios habrá que ganarla poco a poco,
interviniendo en ella mucho más la actitud de los medios de comunicación
y la formación de los usuarios que la verdadera validez del protocolo. El
estándar SSL no contempla la
implementación del No Repudio de mensajes, aunque como veremos en el capítulo seis sería muy simple y fácil dar
soporte a esta característica.
Secure Sockets Layer (SSL).
Netscape desarrolló la primera
versión de SSL en 1994. Está primera versión jamás fue implementada de forma
pública. Tan sólo unos pocos meses después liberó una importante actualización
que vino a llamarse SSL 2.0 y que si tuvo una implementación real a pesar de ir
aquejada de importantes errores de diseño. En noviembre de 1995 Netscape
publica la especificación para SSL 3.0 la cual, desde entonces, se ha convertido en el estándar ‘de
hecho’ para comunicaciones seguras entre clientes y servidores en Internet.
El objetivo de Netscape era crear
un canal de comunicaciones seguro entre un cliente y un servidor que fuese independiente
del sistema operativo usado por ambos y que se beneficiara de forma dinámica y
flexible de los nuevos adelantos en materia
de cifrado a medida de que estos estuvieran disponibles. SSL fue
diseñado como un protocolo seguro de propósito general y no teniendo en mente
las necesidades específicas del comercio electrónico.
SSL trabaja sobre el protocolo
TCP y por debajo de protocolos como HTTP, IMAP, LDAP, etc., y puede ser
usado por todos ellos de forma transparente para el usuario. Opera entre la capa
de transporte y la de sesión del modelo OSI (o entre la capa de transporte y la
de aplicación del modelo TCP) y está formado, a su vez, por dos capas y cuatro
componentes bien diferenciados.
Para facilitar la labor de los
desarrolladores, NETSCAPE mantiene una excelente información sobre SSL. En la
siguiente URL tenemos una traza completa y detallada del intercambio de mensajes y el contenido de
los mismos entre cliente y servidor en dos casos distintos: usando RC4-40 y MD5
y usando RC4-128 y MD5. Para ambos casos tenemos los mensajes correspondientes
a la primera conexión y a una supuesta reanudación de la misma:
Como
hemos dicho anteriormente, SSL es capaz de trabajar de forma transparente con
todos los protocolos que trabajan sobre TCP. La IANA tiene asignado un número
de puerto por defecto acada uno de ellos que podemos ver en la tabla siguiente:
 |
Estos puertos son válidos también para las implementaciones de estos
mismos protocolos sobre TLS.
|
La Competencia de SSL
En el primer grupo tenemos tres
protocolos: S-HTTP, PCT, TLS e IPSec. Todos siguen el mismo esquema: en primer
lugar se invoca un mecanismo para, mediante criptografía asimétrica,
intercambiar una clave secreta de longitud suficiente y, en segundo lugar, se
utiliza esta clave para cifrar la información transmitida mediante un algoritmo simétrico mucho más eficiente.
En el segundo grupo tenemosCyberCash y SET.
Ambos implementan una arquitectura mucho más adecuada y orientada para el
comercio electrónico en base a una tercera parte de confianza que actúa como
intermediaria entre comprador, vendedor y los bancos de ambos.
Problemas de SSL
SSL es el protocolo seguro más usado
y con más implementaciones útiles queexiste en la actualidad. Eso es un hecho.
Pero como hemos ido viendo a lo largo de este blog, ni es el mejor en todo ni
el más idóneo para todas las circunstancias.
El secreto de su éxito no ha
estado sólo en su bondad, sino también en su versatilidad, su facilidad de implementación y su
oportunidad (o lo que se llama estar en el momento justo y el lugar apropiado).
Veremos algunas cosas que SSL no hace bien o no hace en absoluto. Problemas, errores
frecuentes, debilidades y, en algunos casos, formas más o menos costosas de solventarlas
o aliviarlas.
Problemas con Otros Protocolos de la Capa de Transporte
SSL se coloca entre la capa de
transporte y la de sesión y soporta, de
forma transparente, la práctica totalidad de protocolos que se sitúan sobre el
mismo: HTTP, FTP, IMAP, LDAP, etc. Pero, ¿que ocurre por debajo de el?
Desgraciadamente no está concebido para trabajar con otros protocolos de lacapa
de transporte diferentes de TCP y, sobre todo, no orientados a conexión,
algunos de ellos muy usados hoy en día
(como UDP) y otros que han tenido su momento aunque ahora caigan en el desuso
(como es el caso de IPX).
No Repudio de Transacciones
¿Qué es exactamente el no repudio de transacciones?
Imaginemos que uncomprador envía un mensaje pidiendo un producto a un vendedor.
Posteriormente el comprador se retracta y dice que el jamás realizó esa
petición. Un protocolo implementa No Repudio de mensajes cuando permite ante
casos como este que el vendedor demuestre inequívocamente ante una tercera
parte que el comprador y sólo el emitió el mensaje causa de litigo.
Debilidades de SSL
La versión 2.0 de SSL poseía
muchas debilidades que la versión 3.0 se apresuró a corregir: una débil
construcción de los MAC, errores en el mecanismo de HandShake, etc. Aunque, como decimos, la gran mayoría de
estos errores están corregidos, la gran
mayoría de nuestros navegadores y muchos servidores de Internet siguen
aceptando, por motivos de compatibilidad, la versión 2.0 de este protocolo. La
versión 3.0 de SSL es suficientemente robusta para aguantar la gran mayoría
de los ataques y la mayoría de las
debilidades que analizaremos brevemente en esteapartado no son universales,
sino que afectan a determinadas implementaciones más o menos extendidas, del
popular protocolo.
Morales Vázquez, José María. SSL, Secure Sockets Layer y Otros Protocolos Seguros para el Comercio Electrónico. I Edición ed. Madrid, España: Universidad Politécnica de Madrid, 2001/2002. N. pag. Universidad Politécnica de Madrid. Web. 12 Nov. 2014.
Gerardo Gabriel Jimenez Mojarraz
Leonardo Vidal Santiago
Andres Calderon Sacarias
Felipe de Jesus Aguileta Flores
Morales Vázquez, José María. SSL, Secure Sockets Layer y Otros Protocolos Seguros para el Comercio Electrónico. I Edición ed. Madrid, España: Universidad Politécnica de Madrid, 2001/2002. N. pag. Universidad Politécnica de Madrid. Web. 12 Nov. 2014.
Gerardo Gabriel Jimenez Mojarraz
Leonardo Vidal Santiago
Andres Calderon Sacarias
Felipe de Jesus Aguileta Flores
Comentarios
Publicar un comentario