Principios teóricos y prácticos de auditoría SSL

¿Por qué es conveniente auditar SSL?

El principal motivo de auditar SSL no es otro determinar la seguridad de las comunicaciones entre dos entidades determinadas, generalmente, cliente y servidor. Aunque lo asociamos a Web principalmente, otros medios de comunicación hacen uso intensivo de métodos criptográficos para generar comunicaciones seguras, como el correo electrónico o la voz sobre IP. En este texto veremos ejemplos Web, aunque el fundamento teórico es exactamente el mismo.

El principal enemigo de la seguridad de las comunicaciones es la interceptación y descifrado de mensajes dentro de un túnel seguro. En otras palabras, romper la confidencialidad de la información, aunque también es dañina la ruptura de la integridad de los mensajes y el impacto sobre la disponibilidad. Es lo que se llaman ataques Man In The Middle, o MITM, en los que un atacante se establece entre las dos entidades en comunicación con el propósito de interceptar y obtener los contenidos de los mensajes cifrados entre emisor y receptor.

El reciente caso de DigiNotar es un buen ejemplo de lo que pasa cuando por algún motivo, la seguridad del canal queda al descubierto. Los modelos de certificación empleados en Web son un tema de discusión aparte, y no guardan relación directa con la temática que tenemos hoy entre manos, aunque son un buen ejemplo.

En ausencia de un certificado adulterado, es decir, en condiciones normales de operación, ese candadito y esa “s” tras el HTTP de toda la vida se encargan de que personas que no tendrían por que espiar tus comunicaciones fracasen al intentarlo. Y esto es muy importante, habida cuenta que el derecho a tener comunicaciones secretas está recogido en la misma Constitución, y son muchos los delitos que derivan de pasarse por el forro este derecho, como por ejemplo el descubrimiento y revelación de secretos, que forma parte del Código Penal español. El secreto de las comunicaciones es importante, y por tanto, auditar la seguridad de las comunicaciones es extremadamente importante.

Los elementos básicos en seguridad SSL

Lo primero es definir claramente qué vamos a comprobar. En el caso de SSL, hablamos de cinco aspectos principales:

El protocolo empleado
El establecimiento de la comunicación
El cifrado de las comunicaciones
Firmas digitales
El hashing
Códigos de autenticación de mensajes (HMAC)

1. El protocolo empleado

Cronológicamente hablando, SSL (Secure Sockets Layer) es el predecesor de TLS (Transport Layer Security). TLS es un protocolo basado en las especificaciones SSL, originalmente diseñado por Netscape. En este ámbito, SSL 3.0 sirvió de base para definir TLS 1.0, aunque por razones de compatibilidad hacia atrás, TLS sigue siendo compatible con especificaciones estrictamente concernientes a SSL. Aunque no son lo mismo, se tiende a llamar SSL a los dos principales protocolos criptográficos para asegurar comunicaciones a través de Internet, SSL y TLS. Me váis a permitir que yo haga lo mismo, con la idea de facilitar al máximo la comprensión de los conceptos.

Como curiosidad comentar que TLS 1.0 no es algo nuevo. El RFC original es de 1999, aunque últimamente nos complace celebrar cómo servicios Web incorporan cifrado a través de HTTPS en sus servicios, 12 años después de la definición de TLS 1.0. En el caso de SSL la cosa tiene más delito, ya que nos remontamos a 1996, de lo que pronto hará 20 años.

Como punto de partida yo suelo emplear la publicación especial NIST 800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations aunque cada maestrillo tiene su librillo. En esencia, en este documento, se consideran apropiados los protocolos SSL 3.0 y TLS 1.0, aunque debido a que SSL 3.0 no es compatible con FIPS 140, y dado que existen problemas de operación contigua que impiden el uso conjunto de SSL 3.0 y TLS 1.0, NIST se decanta por este último como protocolo a recomendar. Como podéis adivinar, habida cuenta de que la amplia mayoría de clientes soporta TLS, creo que es conveniente recomendar, con independencia de lo que diga FIPS, el uso de TLS 1.0 como protocolo de partida para lograr comunicaciones seguras.

Conviene recordar que la guía NIST data de 2005, con lo que hay que tener en cuenta la evolución de TLS desde entonces hasta ahora. Al hilo de esta evolución, en 2008 se publicó TLS 1.2 (SSL 3.3) y este mismo año, en marzo de 2011, se prohibió finalmente el empleo de SSL 2.0 en el establecimiento de sesiones TLS entre clientes y servidores.

Aunque la guía NIST que enlazo tiene como ámbito de aplicación determinados sistemas gubernamentales en EEUU, creo que es un buen documento para comprender por qué TLS es el camino a seguir. SSL presenta ciertos problemas de interoperabilidad de los que generalmente no se habla, y tiene implicaciones en seguridad que hacen que TLS sea la alternativa adecuada. Desde el punto de vista de la seguridad, SSL usa un modelo de derivación de llaves criptográficas en el que la mitad del secreto se genera únicamente con MD5, al que ya conocemos por sus deficiencias. En el caso de TLS, es necesaria la intervención de MD5 y SHA-1 con lo que se considera resistente a ataques de colisión. El comentado uso MD5 en SSL 3.0 lo hace incompatible compatible con FIPS, de ahí que NIST se decante por este último.

Un punto que hay que dejar claro sobre SSL es que sólo se considera de aceptable en su versión 3.0. Son 4 los problemas principales que hacen obligatoria la prohibición del empleo de SSL 2.0:

La autenticación de mensajes emplea MD5, considerado vulnerable ante eventos de colisión
Los mensajes de establecimiento (handshake) no están protegidos, lo que faculta ataques MITM que pueden forzar al cliente a escoger métodos de cifrado débiles que pueden ser atacados criptográficamente
Tanto la integridad de mensajes como el cifrado de los mismos emplean la misma llave, lo que representa un problema si se fuerza al cliente al uso de cifrado débil
Las sesiones pueden ser fácilmente cerradas por los atacantes sin que exista manera de determinar, desde el cliente, si el cierre de sesión es legitimo o no

Criterio de auditoría para el tipo de protocolo

La presencia de SSL 2.0 se considera directamente una incidencia grave, y se resuelve deshabilitando
La presencia de SSL 3.0 se negocia con los auditados únicamente si existen razones de peso, y me refiero a problemas de soporte con clientes que no implementen TLS 1.0 o superior. Si estas razones no existen, se recomiendará TLS 1.0+
La presencia de TLS 1.0 o superior se considera, en principio, apropiada

2. El establecimiento de la comunicación. Intercambio de claves

El establecimiento de claves es el proceso mediante el cual las partes que se quieren comunicar intercambian una clave secreta compartida, que será empleada para cifrar la comunicación. En el caso de RSA, el más frecuente, el cliente genera una clave aleatoria que es enviada al servidor, mientras que en otros esquemas, como Diffie-Hellman, el servidor genera datos aleatorios, los envía al cliente, el cliente genera datos aleatorios adicionales en combinación con los que recibe del servidor, y la clave resultante es enviada al servidor para ser empleada como secreto compartido.

Además de seleccionar un método criptográfico confiable, el establecimiento debe contar siempre, sin excepción, con autenticación. En general el uso de claves RSA de 1024 bit se considera aceptable, aunque siempre que se pueda, aumentar a 2048 es una buena práctica, especialmente en entornos de alta seguridad, como los financieros transaccionales.

Criterio de auditoría para el establecimiento de comunicación

Claves de longitud inferior a 1024 bit son motivo de incidencia
El intercambio anónimo de claves (sin que medie autenticación) es motivo de incidencia
El uso de claves débiles, como por ejemplo, el problema de seguridad en Debian OpenSSL es motivo de incidencia directa
Se consideran aceptables entornos con autenticación RSA con claves de longitud mínima 1024 bits, aconsejándose si es posible incrementar a 2048
En entornos de alta seguridad, es conveniente recomendar autenticación RSA con intercambio de claves Diffie Hellman efímero
El empleo de otros medios de establecimiento, como Fortezza-KEA u otras variantes Diffie-Hellman, la estática y la anónima, serán objeto de estudio en cada caso, aunque la variante anónima, al carecer de autenticación, no es recomendable. El caso de KEA es distinto, ya que aunque es compatible con SSL 3.0, no lo es con TLS 1.0

3. El cifrado de las comunicaciones

Es el alma mater a considerar, y es el que normalmente acarrea todos los problemas. Es también un punto frecuente de discusión, ya que son varias las opciones que se pueden considerar. Las más usuales son las siguientes:

RC4, que no es compatible con FIPS 140, pero curiosamente es el más empleado en TLS. Emplea longitudes de clave variables entre 8 y 2048 bits
Triple DES-EDE (3DES-EDE), que es compatible con FIPS 140. Emplea bloques de 64 bits y claves de 56 bits diferentes en tres ciclos de aplicación DES
AES, posiblemente el favorito de todos, con claves de 128, 192, o 256 bits. Es válido según FIPS 140 y debe ser escogido preferentemente sobre DES y 3DES

Criterio de auditoría para el cifrado

El empleo de claves de longitud inferior a 128 bits debe ser verificado en casa caso
El empleo de métodos de cifrado inseguros es motivo de incidencia
En general, debe considerarse incidencia a investigar la presencia de métodos de cifrado que no sean RC4, AES o 3DES-EDE

4. Firmas digitales

Para el caso de firma digital las opciones son usualmente dos: RSA y DSA. En el caso de RSA, el firmante genera un resumen del mensaje (digest o hash) y lo cifra con la clave privada. El verificador emplea la clave pública del firmante para descifrar el mensaje, y compara el resumen con el generado localmente para determinar si coinciden. En el caso de DSA, el firmante emplea SHA-1 y su clave privada de firma, y el verificador DSA devuelve un “sí o no” al computar el resumen del mensaje, la firma del firmante y la llave pública.

El cliente emplea la extensión signature_algorithms para indicar al servidor qué pareja de firma/hashing será empleada en el proceso de firma digital.

Criterio de auditoría para la firma

El empleo de algoritmos RSA y DSA se considera aceptable
Otros métodos deben ser analizados caso a caso

5. Hashing

Cuando un mensaje determinado es empleado como punto de entrada en un algoritmo, se obtiene un resumen o digest. Las longitudes de estos mensajes son variables dependiendo del mecanismo empleado. El método de hashing se establece en el handshaking de la comunicación, y se utiliza para asegurar la integridad de los mensajes a través de las HMAC que veremos a continuación.

Los mecanismos de hashing o generación de resúmenes son varios, destancando SHA-1 y MD5. SHA-1 es la recomendación natural, aunque debe tenerse en cuenta que SHA-256, SHA-384, y SHA-512 no están soportados en TLS, si bien MD5 goza de amplia aceptación y debido a la naturaleza de las comunicaciones TLS, se considera válido ya que las HMACs están afectadas en mucha menor proporción, en términos de colisión, que las funciones hashing subyacentes.

Criterio de auditoría para el hashing

HMAC-SHA-1 y HMAC-MD5 se consideran aceptables

6. Código de autenticación de mensajes (HMAC)

Permite, mediante el secreto compartido, dotar a los mensajes de datos adicionales que permiten realizar verificaciones de autenticación e integridad. Es frecuente hablar aquí de HMAC, códigos de autenticación de mensajes obtenidos a través de funciones hash. Los interesados pueden ojear el RFC 2104 para obtener más detalles, pero en síntesis, se trata de obtener un código MAC mediante una función hash y una clave secreta para proteger la integridad de los mensajes.

Criterio de auditoría para HMACs

HMAC depende de la función hash escogida y la clave secreta compartida, luego estos serán los puntos a analizar

Combinando todo lo anterior. El concepto de cipher suites

Una vez hemos identificado los 5 elementos cruciales a considerar en la seguridad en comunicaciones a través de Internet, surge la necesidad de combinarlos. Esta combinación se denomina habitualmente como cipher suite, una nomenclatura en la que se une autenticación, cifrado y códigos de autenticación de mensajes. Durante la negociación, el servidor presenta al cliente la lista de suites disponibles, escogiéndose la de mayor fortaleza entre las disponibles.

Así, por ejemplo, la suite TLS_RSA_WITH_3DES_EDE_CBC_SHA implicará que tenemos TLS como protocolo, RSA para el establecimiento de la comunicación, 3DES-EDE con modo de operación CBC como mecanismo de cifrado y SHA-1 como motor para el cálculo de la HMAC correspondiente. Las suites recomendadas por NIST están publicadas en la guía, y son las siguientes:

cipher suites

Ejemplo 1: Una aplicación web con una configuración de seguridad SSL mejorable

URL: https://wwws.tesoro.es
Descripción: Página para operativa del Tesoro Público
Comando: sslscan –no-failed wwws.tesoro.es:443

Para obtener los detalles de la seguridad SSL de una manera rápida, se puede emplear SSLscan. Me gusta esta herramienta porque presenta la información de una manera ordenada y especialmete útil para detectar rápidamente la presencia de problemas.

De la ejecución sslscan –no-failed www.tesoro.es:443, que arrojará aquellas suites soportadas que no fallan o que no están explícitamente rechazadas, obtenemos que:

Accepted SSLv2 168 bits DES-CBC3-MD5
Accepted SSLv2 128 bits RC2-CBC-MD5
Accepted SSLv2 128 bits RC4-MD5
Accepted SSLv2 56 bits DES-CBC-MD5
Accepted SSLv2 40 bits EXP-RC2-CBC-MD5
Accepted SSLv2 40 bits EXP-RC4-MD5
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted SSLv3 56 bits DES-CBC-SHA
Accepted SSLv3 40 bits EXP-RC2-CBC-MD5
Accepted SSLv3 40 bits EXP-RC4-MD5
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
Accepted TLSv1 56 bits DES-CBC-SHA
Accepted TLSv1 40 bits EXP-RC2-CBC-MD5
Accepted TLSv1 40 bits EXP-RC4-MD5

Los cifrados preferidos del servidor

SSLv2 168 bits DES-CBC3-MD5
SSLv3 128 bits RC4-MD5
TLSv1 128 bits RC4-MD5

Destacan:

La presencia de SSLv2 como cifrado preferido del servidor y otros dos métodos que, aun siendo aceptables, no son los más aconsejables en un servicio de este tipo
Múltiples cipher suites inseguras (todas las SSLv2) y configuraciones SSLv3 y TLSv1 con baja calidad de cifrado (todas las que tienen longitud inferior a 128 bits, y ninguna suite basada en 3DES o AES)
Establecimiento de comunicación con RSA 1024, siendo 2048 más recomendable para entornos transaccionales

Ejemplo: Una aplicación web con una buena configuración seguridad SSL

URL: https://www.twitter.com
Descripción: Versión HTTPS de Twitter
Comando: sslscan –no-failed www.twitter.com:443

Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5

Los cifrados preferidos del servidor

SSLv3 256 bits AES256-SHA
TLSv1 256 bits AES256-SHA

Destacan:

Ni rastro SSLv2 ni de mecanismos de cifrado débiles o de media calidad. Suites reducidas en número
Excelentes suites marcadas como preferidas, ambas de extraordinaria calidad criptográfica
Establecimiento de comunicación con RSA 2048, sobrepasando el mínimo exigido para un entorno de autenticación

Por último … cuidado al recomendar. Navegadores y soporte TLS

Firefox, de momento, sólo soporta TLS 1.0. No soporta TLS 1.1 ni TLS 1.2
TLS 1.2 sólo se soporta en Internet Explorer 8 bajo Windows 7 o Windows Server 2008 R2
Safari soporta TLS, pero Apple no ha divulgado oficialmente qué versión soporta
Opera soporta TLS 1.2

Fuente: Sahw