Protocolo SSL.

Presentación del tema: "Protocolo SSL."— Transcripción de la presentación:

1 Protocolo SSL

2 1 Introducción 2 Propiedades 3 Objetivos 4 Descripción 5 Seguridad 6 Análisis  7 Información Relacionada

3 INTRODUCCION El protocolo SSL (Secure Sockets Layer) fue diseñado con el objeto de proveer privacidad y confiabilidad a la comunicación entre dos aplicaciones. Este se compone de dos capas: SSL Record Protocol. Está ubicada sobre algún protocolo de transporte confiable (como por ejemplo TCP) y es usado para encapsular varios tipos de protocolos de mayor nivel. SSL Handshake Protocol. Es uno de los posibles protocolos que pueden encapsularse sobre la capa anterior y permite al cliente y al servidor autenticarse mutuamente, negociar un algoritmo de cifrado e intercambiar llaves de acceso. Una de las ventajas del SSL es que es independiente del protocolo de aplicación, ya que es posible ubicarlo por encima del mismo en forma transparente.

4 PROPIEDADES Las conexiones realizadas por medio de este protocolo tienen las siguientes propiedades básicas: Privada. Después de un proceso inicial de "handshake" en el cual se define una clave secreta, se envía la información encriptado por medio de algún método simétrico (DES, RC4). Segura. La identidad de cada extremo es autenticada usando métodos de cifrado asimétricos o de clave pública (RSA, DSS). Confiable. El transporte del mensaje incluye un control de la integridad del mismo usando una MAC cifrada con SHA y MD5.

5 OBJETIVOS Los objetivos del protocolo SSL son, en orden de prioridad:
Seguridad Criptográfica. Debe ser usado para establecer una conexión segura entre dos partes. Interoperabilidad. Programadores independientes deben poder desarrollar aplicaciones que, utilizando SSL, permitan intercambiar en forma exitosa parámetros de cifrado sin tener conocimiento del código utilizado por el otro. Flexibilidad. Debe ser una base sobre la cual puedan incorporarse nuevos métodos de cifrado. Esto trae aparejado dos objetivos más: evitar la creación de un protocolo nuevo y la implementación de una nueva biblioteca de seguridad Eficiencia. Dado que las operaciones de cifrado consumen gran cantidad de recursos, en especial CPU, incorpora ciertas facilidades que permiten mejorar este aspecto, además de mejorar el uso de la red.

6 DESCRIPCION SSL es un protocolo estratificado, por lo que en cada capa se le agregan a los mensajes campos con distintos tipos de contenido, como el largo de los mismos, algún tipo de descripción y la información propiamente dicha. Éste toma los mensajes a transmitir, los fragmenta en bloques de un tamaño conveniente, los comprime en caso de ser necesario, les aplica una MAC, los cifra y el resultante de todo esto lo transmite al otro extremo. El proceso inverso implica el descifrado, verificación, descompresión, rearmado y entrega a los clientes de las capas superiores de los datos recibidos.  Una sesión SSL posee diferentes estados y es responsabilidad del SSL Hanshake Protocol la coordinación de los mismos entre el cliente y el servidor para que ambos funcionen en forma consistente, a pesar del hecho que no estén exactamente en paralelo. Además, cada sesión SSL puede tener múltiples conexiones seguras y cada parte puede tener múltiples sesiones seguras.

7 Seguridad Recomendaciones para su implementación
Claves temporarias RSA: Las leyes de exportación de los Estados Unidos limitan las claves RSA usadas para cifrado a 512 bits, pero no ponen ningún limite al largo de las llaves RSA usadas para operaciones de firma digital. Los certificados suelen necesitar tamaños de más de 512 bits, pues estas claves no son lo suficientemente seguras para transacciones de gran tamaño o de gran duración. Algunos certificados son también designados de firma solamente, por lo que no pueden ser usados para intercambio de clave. Cuando la clave pública del certificado no puede ser usada para cifrado, el servidor firma una clave RSA temporaria, la cual es intercambiada. En aplicaciones de exportación, la clave temporaria RSA tiene un tamaño máximo permitido, y dado a que ese tamaño es relativamente inseguro, este debe ser cambiado a menudo. Para aplicaciones de comercio electrónico típicas, se sugiere que las claves sean cambiadas diariamente o cada 500 transacciones como mínimo, debiendo hacerse mas seguido si es posible. La generación de claves RSA es un proceso que consume tiempo, por lo que puede asignarse esta tarea a un proceso de baja prioridad, de modo que una vez terminado éste, se produzca el cambio de la misma

8 ANALISIS SSL fue diseñado para establecer una conexión segura entre un cliente y un servidor comunicándose sobre un canal inseguro. Para este análisis asumiremos que los atacantes tienen herramientas computacionales suficientes y no pueden obtener información secreta de fuentes externas al protocolo. Se asume también que los atacantes tienen la habilidad para capturar, modificar, borrar, reenviar, y hacer lo que se les plazca sobre el canal de comunicaciones. Protocolo de Handshake  Autenticación e intercambio de claves: cuando el servidor es autenticado, el canal debe ser lo suficientemente seguro para evitar los ataques del tipo man-in-the-midle, pero las sesiones anónimas son de por sí vulnerables a este tipo de ataques. Para evitarlas, ambos deben verificar que los certificados sean válidos. El objetivo de un proceso de intercambio de claves es crear un pre_master_secret conocido por las partes intervinientes y no por los atacantes. Este será usado para generar el master_secret, que a su vez se utilizará para generar los mensajes de finalización, claves de cifrado y los mensajes MAC secrets. Enviando un mensaje de finalización correcto, ambas partes prueban que conocen la pre_master_secret correcta.

9 Información relacionada
El CERT, en su Advisory CA-98.07 generado el 26 de junio de 1998, cuya última revisión es del 24 de agosto de 1998, reporta vulnerabilidades en los productos que utilizan PKCS #1, entre los cuales se encuentra el SSL. En él se indica que bajo ciertas circunstancias, un intruso que pueda observar una sesión SSL cifrada, e interrogar el servidor involucrado en la sesión, puede recuperar la clave de sesión usada y recuperar los datos cifrados intercambiados en la misma. Esta vulnerabilidad puede ser explotada solamente si el intruso puede realizar intentos repetidos de establecimiento de sesión al mismo web server que estuvo involucrado en la sesión inicial. Además, el servidor puede devolver mensajes de error que se distinguen entre distintos tipos de fallas. Si bien el número de intentos necesarios es grande, es significativamente mucho más eficiente que un ataque por fuerza bruta a la clave de la sesión. Si bien los web servers componen el conjunto más grande de servidores vulnerables, otros que usen PKCS #1 están en las mismas condiciones Debemos aclarar que las claves públicas y privadas del servidor no están amenazadas por esta vulnerabilidad y que un intruso sólo puede recuperar datos desde una sesión única por cada ataque. Comprometer una sesión no le da al intruso habilidades adicionales para comprometer secuencias subsiguientes. Es más, esta vulnerabilidad no afecta a todas las aplicaciones que usan PKCS #1, sólo aquellas que tienen establecimiento de sesión en forma interactiva o en los que los errores de mensajes devueltos por el servidor se distinguen entre los tipos de fallas. Esto no afecta a S/MIME o SET.

10 BIBLIOGRAFIA