Protección del nivel de transporte-SSL

Un método alternativo que no necesita modificaciones en los equipos de interconexión es introducir la seguridad en los protocolos de transporte.

La solución más usada actualmente es el uso del protocolo SSL o de otros basados en SSL.

Este grupo de protocolos comprende:

• El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los años 90. La primera versión de este protocolo ampliamente difundida y implementada fue la 2.0. Poco después Netscape publicó la versión 3.0, con muchos cambios respecto a la anterior, que hoy ya casi no e utiliza.

• La especificación Transport Layer Security (TLS), elaborada por la IETF (Internet Engineering Task Force). La versión 1.0 del protocolo TLS está publicada en el documento RFC 2246. Es prácticamente equivalente a SSL 3.0 con algunas pequeñas diferencias, por lo que en ciertos contextos se considera el TLS 1.0 como si fuera el protocolo “SSL 3.1”.

• El protocolo Wireless Transport Layer Security (WTLS), perteneciente a la familia de protocolos WAP (Wireless Application Protocol) para el acceso a la red des de dispositivos móviles. La mayoría de los protocolos WAP son adaptaciones de los ya existentes a las características de las comunicaciones inalámbricas, y en particular el WTLS está basado en el TLS 1.0.

Las diferencias se centran principalmente en aspectos relativos a el uso eficiente del ancho de banda y de la capacidad de cálculo de los dispositivos, que puede ser limitada.

En este apartado hablaremos de les características comunes a SSL 3.0 y TLS 1.0, con algún detalle particular a las diferencias entre ellos. La mayoría de referencias a los “protocolos SSL/TLS” se deben entender aplicables también a WTLS.

4.1. Características del protocolo SSL/TLS

El objetivo inicial del diseño del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta protección debía permitir al cliente asegurarse que se había conectado al servidor auténtico, y enviarle datos confidenciales, como por ejemplo un número de tarjeta de crédito, con la confianza que nadie más que el servidor sería capaz de ver estos datos.

Las funciones de seguridad, pero, no se implementaron directamente en el protocolo de aplicación HTTP, si no que se optó por introducirlas a nivel de transporte. De este modo podría haber muchas más aplicaciones que hicieran uso de esta funcionalidad.

Con este fin se desarrolló una interfaz de acceso a los servicios del nivel de Datagramas en WTLS transporte basada en la interfaz estándar de los sockets.

Una característica distintiva del WTLS es que no solamente permite proteger conexiones TCP, como hacen SSL y TLS, si
no que también define un mecanismo de protección para las comunicaciones en modo datagrama, usadas en diversas
aplicaciones móviles.

En esta nueva interfaz, funciones como connect, accept, send o recv fueron sustituidas por otras equivalentes pero que utilizaban un protocolo de transporte seguro: SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseño se realizó de tal modo que cualquier aplicación que utilizara TCP a través de las llamadas de los sockets podía hacer uso del protocolo SSL solamente cambiando estas llamadas. De aquí proviene el nombre del protocolo.

Los servicios de seguridad que proporcionan los protocolos SSL/TLS son:

Confidencialidad. El flujo normal de información en una conexión SSL/TLS consiste en intercambiar paquetes con datos cifrados mediante claves simétricas (por motivos de eficiencia y rapidez). Al inicio de cada sesión, cliente y servidor se ponen de acuerdo en que claves utilizarán para cifrar los datos.

Siempre se utilizan dos claves distintas: una para los paquetes enviados del cliente al servidor, y la otra para los paquetes enviados en sentido contrario. Para evitar que un intruso que esté escuchando el diálogo inicial pueda saber cuales son las claves acordadas, se sigue un mecanismo seguro de intercambio de claves, basado en criptografía de clave pública. El algoritmo concreto para este intercambio también se negocia durante el establecimiento de la conexión.

Autenticación de entidad. Con un protocolo de reto-respuesta basado en firmas digitales el cliente pude confirmar la identidad del servidor al cual se ha conectado. Para validar las firmas el cliente necesita conocer la clave pública del servidor, y esto normalmente se realiza a través de certificados digitales.

SSL/TLS también prevé la autenticación del cliente frente al servidor. Esta posibilidad, pero, no se usa tan a menudo porque muchas veces, en lugar de autenticar automáticamente el cliente a nivel de transporte, las mismas aplicaciones utilizan su propio método de autenticación.

Autenticación de cliente. Un ejemplo de autenticación de cliente a nivel de aplicación son las contraseñas que pueden
introducir los usuarios en formularios HTML. Si la aplicación utiliza este método, al servidor ya no le hace falta autenticar al
cliente a nivel de transporte.

Autenticación de mensaje. Cada paquete enviado en una conexión SSL/TLS, a más de ir cifrado, puede incorporar un código MAC para que el destinatario compruebe que nadie ha modificado el paquete. Las claves secretas par el cálculo de los códigos MAC (una para cada sentido) también se acuerdan de forma segura en el diálogo inicial.

A más, los protocolos SSL/TLS están diseñados con estos criterios adicionales: Eficiencia. Dos de las características de SSL/TLS, la definición de sesiones y la compresión de los datos, permiten mejorar la eficiencia de la comunicación.

• Si el cliente pide dos o más conexiones simultáneas o muy seguidas, en lugar de repetir la autenticación y el intercambio de claves (operaciones computacionalmente costosas porque intervienen algoritmos de clave pública), hay la opción de reutilizar los parámetros previamente acordados.

Conexiones consecutivas o simultáneas Una situación típica en que se utiliza SSL/TLS es la de un navegador web que accede a una página HTML que contiene imágenes: con HTTP “no persistente” (el único modo definido en HTTP 1.0), esto requiere
una primera conexión para la página y a continuación tantas conexiones como imágenes haya. Si las conexiones pertenecen a
la misma sesión SSL/TLS, sólo hace falta realizar la negociación una vez. Si se hace uso de esta opción, se considera que la nueva conexión pertenece a la misma sesión que la anterior. En el establecimiento de cada conexión se especifica un identificador de sesión, que permite saber si la conexión empieza una sesión nueva o es continuación de otra.

• SSL/TLS prevé la negociación de algoritmos de compresión para los datos intercambiados, para compensar el tráfico adicional que introduce la seguridad. Pero ni SSL 3.0 ni TLS 1.0 especifican ningún algoritmo concreto de compresión.

Extensibilidad. Al inicio de cada sesión, cliente y servidor negocian los algoritmos que utilizarán para el intercambio de claves, la autenticación y el cifrado (a más del algoritmo de compresión). Las especificaciones de los protocolos incluyen unas combinaciones predefinidas de algoritmos criptográficos,pero dejan abierta la posibilidad de añadir nuevos algoritmos si se descubren otros que sean más eficientes o más seguros.

Fuente:

Aspectos avanzados de seguridad en redes
UOC
Jordi Herrera Joancomartí (coord.)
Joaquín García Alfaro
XP04/90789/00892
Xavier Perramón Tornil 

Si quieres conocer otros artículos parecidos a Protección del nivel de transporte-SSL puedes visitar la categoría SEGURIDAD INFORMATICA.