Transacciones seguras (VII)
por Luciano Moreno, del departamento de diseño web de BJS Software.

Implementación del protocolo SSL.-

Por la parte del cliente, SSL viene implementado por defecto en los navegadores Internet Explorer y Nestcape Navigator, lo que permite a cualquier usuario con uno de estos navegadores poder realizar compras por Internet de forma segura sin tener que conocer el sistema a fondo ni preocuparse de instalar programas adicionales (por lo menos autenticando al servidor web y con confidencialidad e integridad asegurada en la transacción).

La implementación en la parte servidora (la tienda o banco por lo general) es un poco más compleja. En primer lugar, es obligatoria la obtención de un Certificado Digital para el vendedor o para el servidor seguro, solicitándolo a una Autoridad Certificadora de prestigio reconocido, conveniendo, si es posible, que dicha autoridad sea Verisign, ya que la misma está considerada como de toda confianza por los navegadores cliente, por lo que viene activada por defecto en los navegadores cliente.

Ya con el servidor certificado, el usuario podrá realizar su compra. En el momento del pago, el vendedor obtiene el PIN de la tarjeta de crédito del cliente, la fecha de caducidad y sus datos personales (si el pago se realiza por este método), por lo que deberá disponer de algún sistema que permita el envío de estos datos a una entidad financiera capaz de realizar la transferencia bancaria necesaria para completar el pago.

Existen en España diferentes entidades bancarias y financieras que ofrecen estos sistemas a los comerciantes, realizándose la comunicación entre comerciante y banco a través de un protocolo seguro privado en la mayoría de los casos, de forma similar a lo que ocurre cuando pagamos en una tienda "real" con nuestra tarjeta de crédito. Estos sistemas se suelen conocer con el nombre genérico de Pasarelas de Pago.

Un sistema de pasarela más avanzado es el denominado TPV, Terminal de Punto de Venta. En el mismo se conecta una terminal especial al servidor web del vendedor, y mediante un software basado en script CGI se realiza la comunicación segura entre ellos.

Existen en la actualidad diferentes versiones del conjunto de protocolos SSL que se pueden implementar en los distintos servidores y que corren bajo los sistemas operativos más comunes (IIS en Windows NT-2000-XP, Apache en Unix, etc.).

Ventajas e inconvenientes de SSL.-

La tecnología basada en los protocolos Secure Socket Layer proporcionó grandes avances en la implantación de sistemas de comunicación seguros, que han hecho posible un crecimiento importante en las transacciones por Internet. Si estudiamos SSL desde el punto de vista de las bases necesarias para considerar una comunicación segura podemos sacar las siguientes conclusiones:

1. Autenticidad: SSL requiere para su funcionamiento la identificación del servidor web ante el cliente y la realiza adecuadamente, pero normalmente no se pruduce una identificación en sentido contrario. Es decir, no es obligada en la mayoría de los casos la presencia del certificado del usuario que se está conectando al servidor.

Por ejemplo, una de las aplicaciones más comunes de SSL es el de las aplicaciones bancarias. Cuando nos conectamos a la página web de nuestro banco para consultar las cuentas o realizar alguna operación, el servidor web tan sólo nos pide las contraseñas de acceso, lo que conlleva los típicos problemas a la hora de manejar claves: cambiarlas cada cierto tiempo, mantenerlas bien protegidas, elegirlas adecuadamente, etc. Y el tema e complica cuando tenemos que seguir las mismas precauciones con cada una de las diferentes claves que los diferentes bancos y servidores seguros nos requieren.

Otro de los usos comunes de SSL es la protección de números de tarjetas de crédito o débito en compras por Internet. Pero como no se exije el uso del Certificado de Cliente, cualquier persona que obtenga el número de nuestra tarjeta y unos pocos datos personales nuestros puede realizar compras en nuestro nombre. Esto conlleva el tener que prestar mucha atención a los resguardos de nuetras operaciones en cajeros automáticos, a desconfiar cuando un empleado de una tienda o cafetería desaparece con nuestra tarjeta para cobrar el importe de nuestra compra, etc.

Este es precisamente uno de los tipos de fraude más comunes y que causa mayores pérdidas a las compañías de crédito, lo que origina que éstas añadan una comisión en las compras bastante elevada (sobre un 5%), lo que incrementa el precio final del producto a la venta.

2. Confidencialidad: SSL proporciona una buena seguridad de que los datos no van a ser capturados por extraños de forma útil en el proceso de transferencia de los mismos, pero no proporciona ninguna seguridad después de finalizar la conexión.

Supongamos que realizamos una compra por Internet, para la cual enviamos los datos de nuestra tarjeta de crédito mediante SSL. Dichos datos quedan en poder del responsable de la tienda, que normalmente los almacena en una base de datos. Con ello, el número de nuestra tarjeta y demás datos quedan en un medio que no controlamos y que no tiene porqué ser seguro, pudiendo tener acceso a los mismos cualquier empleado de la tienda, un hacker que entre en el ordenador en el que reside la base de datos, etc.

3. Integridad: ocurre algo parecido a lo anterior. En el corto proceso que dura el envío de datos sí podemos estar seguros de que éstos no van a ser modificados, puesto que SSL lo impide. Pero una vez que finaliza la conexión segura no podemos estar tranquilos.

Imaginemos ahora que trás realizar nuestra compra el responsable de la tienda decide cambiar los datos del pedido, y en vez de enviarnos una regrabadora a 30.000 pesetas nos envía 5 a 40.000 pesetas. ¿Qué podemos haces cuando nos llegen a casa las regrabadoras y la factura del banco?. Nada, protestar, patalear y llorar, pero nada más, ya que no hay ningún recibo válido del pedido que hicimos.

4. No Repudio: en este aspecto SSL falla al máximo, ya que no hay por defecto establecido nigún método para dejar constancia de cuándo se ha realizado una operación, cuál ha sido y quiénes han intervenido en ella. SSL no proporciona formas de emitir recibos válidos que identifiquen una transacción.

Vamos ahora a suponer que realizamos un pedido a una tienda on-line, un ordenador por ejemplo, y que cuando nos llega a casa decimos que nosotros no hemos hecho ninguna compra, devolvemos el ordenador y requerimos la devolución del dinero. ¿Cómo puede demostrar el comerciante que en verdad le hicimos el pedido?. Mediante SSL, de ninguna forma.

A todo esto hay que añadir que SSL sólo proporciona seguridad en la transacción cliente-servidor seguro, pero queda otra fase de la transacción, la que va desde el servidor seguro a la empresa emisora de la tarjeta de crédito, y sobre ésta no tenemos ningún tipo de control.

Con SSL toda la seguridad de la transacción recae en la confianza que el cliente tenga en el vendedor, pués en las manos del mismo está el ser honrado y no realizar ningún fraude con los datos obtenidos y en la posterior entrega del producto comprado. Por este motivo, sólo las empresas con una honradez demostrada podrán a priori ganarse la confianza de los potenciales clientes.

Vemos pués que SSL carace de muchos de los elementos necesarios para construir un sistema de transacciones seguras usando Internet. Para intentar paliar estos fallos se han intentado sacar al mercado y estándarizar otros sistemas diferentes, como SET, que veremos a continuación, pero el caso es que hasta ahora ninguno de ellos ha conseguido desplazar a SSL. ¿Porqué?.

Tal vez sea porque, a pesar de sus fallos, SSSL es una tecnología rápida, fácil de implementar, barata y cómoda para el usuario, que no tiene que conocer cómo funciona, tan sólo usarla. Y desde el punto de vista del comerciante o de la empresa que le facilita el hosting, SSL es igualmente sencillo de implementar, no precisando de servidores de especiales características.

Otros protocolos seguros.-

Protocolo TLS - Transport Layer Security.-

Para intentar corregir las deficiencias observadas en SSL v3 se buscó un nuevo protocolo que permitiera transacciones seguras por Internet, sobre todo teniendo en cuenta que SSL es propiedad de la empresa Nestcape. El resultado de esta búsqueda fué el protocolo TLS, que permite una compatibilidad total con SSL siendo un protocolo público, estandarizado por el IETF.

TLS busca integrar en un esquema tipo SSL al sistema operativo, a nivel de la capa TCP/IP, para que el efecto "tunel" que se implementó con SSL sea realmente transparente a las aplicaciones que se están ejecutando. Parte de las mismas bases que SSL, pero se diferencia de él en varios aspectos fundamentales:

1. En el paso CertificateRequest del protocolo Handshake los clientes sólo contestan con un mensaje si son SSL.

2. Las claves de sesión se calculan de forma diferente.

3. A la hora de intercambiar las claves, TLS no soporta el algoritmo simétrico Fortezza, que sí es soportado por SSL. Esto es debido a la búsqueda de un código público, ya que Fortezza es de propiedad privada.

4. TLS utiliza dos campos más en el MAC que SSL, lo que lo hace más seguro.

A pesar de mejorar SSL y de ser público, TLS no está teniendo la aceptación que se esperaba (por lo menos por ahora).

Protocolo S-HTTP.-

El protocolo Secure HTTP fué desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticación mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicación. Se puede identificar rápidamente a una página web servida con este protocolo porque la extensión de la misma pasa a ser .shtml en vez de .html como las páginas normales.

El mecanismo de conexión mediante S-HTTP, que ahora se encuentra en su versión 1.1, comprende una serie de pasos parecidos a los usados en SSL, en los que cliente y servidor se intercambian una serie de datos formateados que incluyen los algoritmos criptográficos, longitudes de clave y algoritmos de compresión a usar durante la comunicación segura.

En cuanto a estos algoritmos, lo usados normalmente son RSA para intercambio de claves simétricas, MD2, MD5 o NIST-SHS como funciones hash de resumen, DES, IDEA, RC4 o CDMF como algoritmos simétricos y PEM o PKCS-7 como algoritmos de encapsulamiento.

A diferencia de SSL, el protocolo S-HTTP está integrado con HTTP, actuando a nivel de aplicación, como ya hemos dicho, negociándose los servicios de seguridad a través de cabeceras y atributos de página, por lo que los servicios S-HTTP están sólo disponibles para el protocolo HTTP. Recordemos que SSL puede ser usado por otros protocolos diferentes de HTTP, pués se integra a nivel de shocked.