ÍNDICE
ÍNDICE
ÍNDICEUna 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.
El estado de las sesiones incluye los siguientes elementos:
Session
Identifier: Es una secuencia arbitraria de bytes elegida por el servidor
para identificar una sesión en estado activo o retomable.
Peer
Certificate: Certificado X509 de la parte. Puede ser nulo.
Compression
Method: El algoritmo utilizado antes de realizar el encriptado.
Cipher
Spec: Especifica el algoritmo de compresión de los datos (puede
ser ninguno, DES, etc.) y el algoritmo para la MAC, tal como MD5 o SHA.
Master
Secret: Es un secret de 48 bytes compartido entre el cliente y el servidor.
Is
Resumable: Es un flag que indica si la sesión puede ser utilizada
para iniciar nuevas conexiones.
Server
and Client Random: Secuencia de bytes elegidas por el servidor y el cliente
para cada conexión.
Server
Write MAC Secret: Es el secret usado en operaciones MAC sobre datos escritos
por el servidor.
Client
Write MAC Secret: Es el secret usado en operaciones MAC sobre datos escritos
por el cliente.
Server
Write Key: Es la clave de cifrado para los datos que van del servidor al
cliente.
Client
Write Key: Es la clave de cifrado para los datos van del cliente al servidor.
Initialization
Vectors: Utilizado para bloques de cifrado en estado CBC.
Sequence
Numbers: Cada parte mantiene una secuencia separada de números para
los mensajes transmitidos y recibidos para cada conexión. Cuando
una de las partes envía o recibe un mensaje de cambio Cipher Spec,
la secuencia correspondiente es puesta a cero.
Los mensajes de alerta pueden ser de los
siguientes tipos:
Cierre:
El cliente y el servidor deben saber cuando la conexión será
cerrada para evitar un ataque por truncado.
Error:
Cuando un error es detectado, la parte que lo detectó envía
una alerta a la otra parte.
Luego, el servidor enviará sus certificados en caso que deba autenticarse y un mensaje de intercambio de claves si se le es requerido. Después de esto solicitará los certificados al cliente (sólo si es necesario), enviará un mensaje Server Hello Done, indicando que la fase de saludo inicial ha terminado y esperará la respuesta del cliente. El cliente enviará su certificado o un mensaje de alerta en caso de no poseerlo y su mensaje de intercambio de clave, cuyo contenido dependerá del algoritmo de clave pública seleccionado en la primera instancia. Si el cliente envió un certificado con posibilidad de ser firmado, un certificado de verificación firmado digitalmente será enviado en esta instancia.
Aquí, un mensaje de cambio de Cipher Spec es enviado por el cliente, guardándolo en estado pendiente. Inmediatamente después envía el mensaje terminado bajo los nuevos algoritmos, claves y secrets. En respuesta, el servidor enviará su propio mensaje de cambio de Cipher Spec, lo transferirá de pendiente a corriente y enviará el mensaje de terminado bajo la nueva Cipher Spec. En este punto, el proceso de handshake se ha completado y las partes pueden comenzar a intercambiar información.
Cuando el cliente y el servidor deciden retomar una sesión previa o duplicar una existente en lugar de negociar nuevos parámetros de seguridad, el flujo de mensajes es el siguiente:
El cliente envía un ClientHello usando la SessionID de la sesión que será retomada. Entonces el servidor controla su cache de sesiones y si la encuentra y está dispuesto a restablecerla bajo el estado especificado, enviará un ServerHello con el mismo valor de ServerID. En este punto, ambos cliente y servidor deben enviar mensajes de cambio de Cipher Spec proceder directamente a los mensajes terminados. Una vez que el proceso termina, el cliente y el servidor pueden comenzar a intercambiar datos de la capa de aplicación. Si no se encuentra la SessionID en el cache, el servidor genera una nueva SessionID y se realiza un proceso de handshake completo.
Los mensajes con datos de las aplicaciones
son llevados por la capa SSL Record Layer en forma transparente y son fragmentados,
comprimidos y encriptados de acuerdo al estado de la conexión.
ÍNDICE
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.
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.
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.
Ataques
de cambio de versión: dado que la versión 3.0 incluye mejoras
sustanciales con respecto a la versión 2.0 y que existe compatibilidad
hacia atrás entre ambas, es probable que los atacantes intenten
que clientes y servidores capaces de comprender mensajes versión
3.0 comiencen a funcionar en versión 2.0. Este ataque puede ocurrir
si y solo si dos partes que soporten SSL versión 3.0 realizan un
handshake versión 2.0. Aunque usar padding de mensajes con bloques
no aleatorios PKCS #1 (Public Key Criptography Standard #1 - Norma de Cifrado
con Clave Pública n°1 de los laboratorios RSA) del tipo
2 no es una solución elegante, provee una forma segura para detectar
los ataques a los servidores version 3.0. Esta solución no es buena
contra atacantes que puedan obtener con fuerza bruta la clave y substituir
con un nuevo ENCRYPTED-KEY-DATA conteniendo la misma clave (pero con padding
normal) antes que el límite de espera especificado para la aplicación
expire. Partes que estén enteradas de estos tipos de ataques no
deben usar claves de cifrado de 40 bits de ninguna manera. Alterar el padding
de los 8 bytes menos significativos del PKCS no impacta en la seguridad,
ya que es lo mismo que aumentar el tamaño de bloque de entrada en
8 bytes.
Ataques
contra el protocolo de handshake: un atacante puede tratar de influir el
proceso de handshake de modo que las partes elijan algoritmos de cifrado
diferente a los que normalmente elegirían. Dado que muchas implementaciones
soportan cifrado de 40 bits y algunos soportan cifrado nulo o algoritmos
MAC, este tipo de ataque es de importancia. Para este realizarlo, el atacante
debe cambiar en forma activa uno o mas mensajes de handshake. Si esto ocurre,
el cliente y el servidor computaran valores diferentes para los hashes
de los mensajes de handshake. Como resultado, las partes no aceptarán
los mensajes de finalización enviados entre sí. Sin el master_secret,
el atacante no puede reparar los mensajes de finalización, por lo
que el atacante es descubierto.
Retomando
sesiones: cuando una conexión es establecida por medio de la retoma
de una anterior, a los nuevos ClientHello.random y ServerHello.random se
les aplica el master_secret de la sesión. Sabiendo que el master_secret
no se encuentra comprometido y que las operaciones realizadas para producir
las claves de cifrado y los MAC secrets son seguras, entonces la conexión
debe ser segura y efectivamente independiente de conexiones previas. Los
atacantes no pueden usar claves de cifrado o MAC secrets para comprometer
el master_secret sin romper las operaciones realizadas con los protocolos
de hashing (las cuales usan SHA y MD5). Las sesiones no pueden ser retomadas
a menos que ambas partes estén de acuerdo. Si alguna de las partes
sospecha que la sesión ha sido comprometida, o que los certificados
han expirado o han sido revocados, pueden forzar un nuevo handshake completo.
Un límite superior de 24 horas es el sugerido para el de la vida
de un sessionID, pues un atacante que obtenga una master_secret puede impersonarse
como la parte comprometida hasta que la correspondiente sessionID es retirada.
Aplicaciones que pueden correr en ambientes relativamente inseguros no
deben escribir los sessionID en almacenamiento persistente.
MD5
y SHA: SSL usa las funciones de hashing en forma muy conservadora. Cuando
es posible, ambos MD5 y SHA son usados en tandem para asegurar que fallas
en uno de los protocolos rompan el funcionamiento de todo el protocolo.
Datos
de las Aplicaciones
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.
Fue, además, propuesto un desafío para romper una sesión realizada en SSL. El resultado tomó bastante tiempo en llegar (15 días) y fue realizado gracias a la ayuda de varias máquinas trabajando en paralelo, con un método de fuerza bruta. Este "ataque" sólo logró quebrar una de las claves pertenecientes a una única sesión, por lo cual no afecta a cualquiera de las otras sesiones abiertas en ese servidor. Información sobre esto puede encontrarse en la página de Damien Doligez y Adam Back.
ÍNDICE