PROTOCOLO SSL ERIKA JAZMÍN GUERRERO BARAJAS MÓNICA ELIZABETH VÉLEZ LUNA

INTRODUCCIÓN ¿Para que me sirve el protocolo? ¿Para que me sirve el protocolo? Propiedades……………………………………………………………………………....Propiedades……………………………………………………………………………....4 Descripción……………………………………………………………………………..….Descripción……………………………………………………………………………..….5 Seguridad…………………………………………………………………………… Seguridad…………………………………………………………………………… Análisis………………………………………………………………………………….…Análisis………………………………………………………………………………….…9 Bibliografía………………………………………………………………………………Bibliografía………………………………………………………………………………10

¿Para que me sirve el protocolo? 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.

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 encriptada por medio de algún método simétrico (DES, RC4). Segura. La identidad de cada extremo es autenticada usando métodos de ciftrado 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.

Descripción 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. 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

Los parámetros de cifrado del estado de una sesión son generados por el protocolo SSL Handshake Protocol, el cual funciona por encima del SSL Record Layer. Cuando un cliente y un servidor inician una conexión, se ponen de acuerdo en la versión del protocolo y el algoritmo de cifrado, en ocasiones se autentican entre sí, y usan técnicas de cifrado de clave pública para generar los secrets compartidos. Estos procesos son llevados a cabo por el protocolo de hanshake, el cual puede ser resumido como: El cliente envía un mensaje Client Hello al cual el servidor debe responder con un mensaje Server Hello, en caso contrario ocurrirá un error fatal y la conexión fallará. Estos mensajes son usados para establecer los siguientes atributos: Protocol Version (versión del protocolo), Session ID (identificador de la sesión), Cipher Suite (conjunto de cifrado), y Compression Method (método de compresión). Adicionalmente, se intercambian dos valores generados al azar: ClientHello.random y ServerHello.random.

Generación de números aleatorios y sus semillas: SSL requiere un generador de números aleatorios seguros desde el punto de vista del cifrado, por lo que debe tenerse cuidado en el diseño de los mismos y de sus semillas. Se consideran aceptables aquellos usados en operaciones seguras de hashing, como MD5 o SHA, pero por supuesto no pueden dar mas seguridad que el tamaño del generador de estado de número aleatorio (por ejemplo, los generadores basados en MD5 usualmente proveen estados de 128-bits) Certificados y autenticación: las implementaciones son responsables de verificar la integridad de los certificados y deberían generalmente soportar mensajes de revocación de certificados. Los certificados deben ser verificados siempre por una CA (Certificate Authority - Autoridad de Certificación) para asegurar que sean firmados correctamente. CipherSuites - Conjuntos de cifrado: SSL soporta un cierto rango de tamaños de claves y niveles de seguridad, incluyendo algunos que son prácticamente inseguros. Es probable que una implementación realizada correctamente no acepte cierto tipo de Cipher Suites. Por ejemplo, un cifrado de 40 bits puede ser roto fácilmente, por lo que implementaciones que requieran de mucha seguridad no deben permitir claves de 40 bits. Deben evitarse comunicaciones anónimas, pues es pueden realizarse ataques del tipo man-in-the-middle (un hombre en el medio) y deben imponer límites mínimos y máximos en el tamaño de las claves.

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.

Análisis 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.

Bibliografía ypedia009.pdf