\u00bfPor qu\u00e9 es conveniente auditar SSL?<\/p>\n
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\u00f3n hacen uso intensivo de m\u00e9todos criptogr\u00e1ficos para generar comunicaciones seguras, como el correo electr\u00f3nico o la voz sobre IP. En este texto veremos ejemplos Web, aunque el fundamento te\u00f3rico es exactamente el mismo.<\/p>\n
El principal enemigo de la seguridad de las comunicaciones es la interceptaci\u00f3n y descifrado de mensajes dentro de un t\u00fanel seguro. En otras palabras, romper la confidencialidad de la informaci\u00f3n, aunque tambi\u00e9n es da\u00f1ina 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\u00f3n con el prop\u00f3sito de interceptar y obtener los contenidos de los mensajes cifrados entre emisor y receptor.<\/p>\n
El reciente caso de DigiNotar es un buen ejemplo de lo que pasa cuando por alg\u00fan motivo, la seguridad del canal queda al descubierto. Los modelos de certificaci\u00f3n empleados en Web son un tema de discusi\u00f3n aparte, y no guardan relaci\u00f3n directa con la tem\u00e1tica que tenemos hoy entre manos, aunque son un buen ejemplo.<\/p>\n
En ausencia de un certificado adulterado, es decir, en condiciones normales de operaci\u00f3n, ese candadito y esa “s” tras el HTTP de toda la vida se encargan de que personas que no tendr\u00edan por que espiar tus comunicaciones fracasen al intentarlo. Y esto es muy importante, habida cuenta que el derecho a tener comunicaciones secretas est\u00e1 recogido en la misma Constituci\u00f3n, y son muchos los delitos que derivan de pasarse por el forro este derecho, como por ejemplo el descubrimiento y revelaci\u00f3n de secretos, que forma parte del C\u00f3digo Penal espa\u00f1ol. El secreto de las comunicaciones es importante, y por tanto, auditar la seguridad de las comunicaciones es extremadamente importante.<\/p>\n
Los elementos b\u00e1sicos en seguridad SSL<\/p>\n
Lo primero es definir claramente qu\u00e9 vamos a comprobar. En el caso de SSL, hablamos de cinco aspectos principales:<\/p>\n
El protocolo empleado
\nEl establecimiento de la comunicaci\u00f3n
\nEl cifrado de las comunicaciones
\nFirmas digitales
\nEl hashing
\nC\u00f3digos de autenticaci\u00f3n de mensajes (HMAC)<\/p>\n
1. El protocolo empleado<\/p>\n
Cronol\u00f3gicamente hablando, SSL (Secure Sockets Layer) es el predecesor de TLS (Transport Layer Security). TLS es un protocolo basado en las especificaciones SSL, originalmente dise\u00f1ado por Netscape. En este \u00e1mbito, SSL 3.0 sirvi\u00f3 de base para definir TLS 1.0, aunque por razones de compatibilidad hacia atr\u00e1s, 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\u00e1ficos para asegurar comunicaciones a trav\u00e9s de Internet, SSL y TLS. Me v\u00e1is a permitir que yo haga lo mismo, con la idea de facilitar al m\u00e1ximo la comprensi\u00f3n de los conceptos.<\/p>\n
Como curiosidad comentar que TLS 1.0 no es algo nuevo. El RFC original es de 1999, aunque \u00faltimamente nos complace celebrar c\u00f3mo servicios Web incorporan cifrado a trav\u00e9s de HTTPS en sus servicios, 12 a\u00f1os despu\u00e9s de la definici\u00f3n de TLS 1.0. En el caso de SSL la cosa tiene m\u00e1s delito, ya que nos remontamos a 1996, de lo que pronto har\u00e1 20 a\u00f1os.<\/p>\n
Como punto de partida yo suelo emplear la publicaci\u00f3n 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\u00f3n contigua que impiden el uso conjunto de SSL 3.0 y TLS 1.0, NIST se decanta por este \u00faltimo como protocolo a recomendar. Como pod\u00e9is adivinar, habida cuenta de que la amplia mayor\u00eda 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.<\/p>\n
Conviene recordar que la gu\u00eda NIST data de 2005, con lo que hay que tener en cuenta la evoluci\u00f3n de TLS desde entonces hasta ahora. Al hilo de esta evoluci\u00f3n, en 2008 se public\u00f3 TLS 1.2 (SSL 3.3) y este mismo a\u00f1o, en marzo de 2011, se prohibi\u00f3 finalmente el empleo de SSL 2.0 en el establecimiento de sesiones TLS entre clientes y servidores.<\/p>\n
Aunque la gu\u00eda NIST que enlazo tiene como \u00e1mbito de aplicaci\u00f3n determinados sistemas gubernamentales en EEUU, creo que es un buen documento para comprender por qu\u00e9 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\u00f3n de llaves criptogr\u00e1ficas en el que la mitad del secreto se genera \u00fanicamente con MD5, al que ya conocemos por sus deficiencias. En el caso de TLS, es necesaria la intervenci\u00f3n de MD5 y SHA-1 con lo que se considera resistente a ataques de colisi\u00f3n. El comentado uso MD5 en SSL 3.0 lo hace incompatible compatible con FIPS, de ah\u00ed que NIST se decante por este \u00faltimo.<\/p>\n
Un punto que hay que dejar claro sobre SSL es que s\u00f3lo se considera de aceptable en su versi\u00f3n 3.0. Son 4 los problemas principales que hacen obligatoria la prohibici\u00f3n del empleo de SSL 2.0:<\/p>\n
La autenticaci\u00f3n de mensajes emplea MD5, considerado vulnerable ante eventos de colisi\u00f3n
\nLos mensajes de establecimiento (handshake) no est\u00e1n protegidos, lo que faculta ataques MITM que pueden forzar al cliente a escoger m\u00e9todos de cifrado d\u00e9biles que pueden ser atacados criptogr\u00e1ficamente
\nTanto 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\u00e9bil
\nLas sesiones pueden ser f\u00e1cilmente cerradas por los atacantes sin que exista manera de determinar, desde el cliente, si el cierre de sesi\u00f3n es legitimo o no<\/p>\n
Criterio de auditor\u00eda para el tipo de protocolo<\/p>\n
La presencia de SSL 2.0 se considera directamente una incidencia grave, y se resuelve deshabilitando
\nLa presencia de SSL 3.0 se negocia con los auditados \u00fanicamente 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\u00e1 TLS 1.0+
\nLa presencia de TLS 1.0 o superior se considera, en principio, apropiada<\/p>\n
2. El establecimiento de la comunicaci\u00f3n. Intercambio de claves<\/p>\n
El establecimiento de claves es el proceso mediante el cual las partes que se quieren comunicar intercambian una clave secreta compartida, que ser\u00e1 empleada para cifrar la comunicaci\u00f3n. En el caso de RSA, el m\u00e1s 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\u00eda al cliente, el cliente genera datos aleatorios adicionales en combinaci\u00f3n con los que recibe del servidor, y la clave resultante es enviada al servidor para ser empleada como secreto compartido.<\/p>\n
Adem\u00e1s de seleccionar un m\u00e9todo criptogr\u00e1fico confiable, el establecimiento debe contar siempre, sin excepci\u00f3n, con autenticaci\u00f3n. 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\u00e1ctica, especialmente en entornos de alta seguridad, como los financieros transaccionales.<\/p>\n
Criterio de auditor\u00eda para el establecimiento de comunicaci\u00f3n<\/p>\n
Claves de longitud inferior a 1024 bit son motivo de incidencia
\nEl intercambio an\u00f3nimo de claves (sin que medie autenticaci\u00f3n) es motivo de incidencia
\nEl uso de claves d\u00e9biles, como por ejemplo, el problema de seguridad en Debian OpenSSL es motivo de incidencia directa
\nSe consideran aceptables entornos con autenticaci\u00f3n RSA con claves de longitud m\u00ednima 1024 bits, aconsej\u00e1ndose si es posible incrementar a 2048
\nEn entornos de alta seguridad, es conveniente recomendar autenticaci\u00f3n RSA con intercambio de claves Diffie Hellman ef\u00edmero
\nEl empleo de otros medios de establecimiento, como Fortezza-KEA u otras variantes Diffie-Hellman, la est\u00e1tica y la an\u00f3nima, ser\u00e1n objeto de estudio en cada caso, aunque la variante an\u00f3nima, al carecer de autenticaci\u00f3n, 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<\/p>\n
3. El cifrado de las comunicaciones<\/p>\n
Es el alma mater a considerar, y es el que normalmente acarrea todos los problemas. Es tambi\u00e9n un punto frecuente de discusi\u00f3n, ya que son varias las opciones que se pueden considerar. Las m\u00e1s usuales son las siguientes:<\/p>\n
RC4, que no es compatible con FIPS 140, pero curiosamente es el m\u00e1s empleado en TLS. Emplea longitudes de clave variables entre 8 y 2048 bits
\nTriple 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\u00f3n DES
\nAES, posiblemente el favorito de todos, con claves de 128, 192, o 256 bits. Es v\u00e1lido seg\u00fan FIPS 140 y debe ser escogido preferentemente sobre DES y 3DES<\/p>\n
Criterio de auditor\u00eda para el cifrado<\/p>\n
El empleo de claves de longitud inferior a 128 bits debe ser verificado en casa caso
\nEl empleo de m\u00e9todos de cifrado inseguros es motivo de incidencia
\nEn general, debe considerarse incidencia a investigar la presencia de m\u00e9todos de cifrado que no sean RC4, AES o 3DES-EDE<\/p>\n
4. Firmas digitales<\/p>\n
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\u00fablica 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\u00ed o no” al computar el resumen del mensaje, la firma del firmante y la llave p\u00fablica.<\/p>\n
El cliente emplea la extensi\u00f3n signature_algorithms para indicar al servidor qu\u00e9 pareja de firma\/hashing ser\u00e1 empleada en el proceso de firma digital.<\/p>\n
Criterio de auditor\u00eda para la firma<\/p>\n
El empleo de algoritmos RSA y DSA se considera aceptable
\nOtros m\u00e9todos deben ser analizados caso a caso<\/p>\n
5. Hashing<\/p>\n
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\u00e9todo de hashing se establece en el handshaking de la comunicaci\u00f3n, y se utiliza para asegurar la integridad de los mensajes a trav\u00e9s de las HMAC que veremos a continuaci\u00f3n.<\/p>\n
Los mecanismos de hashing o generaci\u00f3n de res\u00famenes son varios, destancando SHA-1 y MD5. SHA-1 es la recomendaci\u00f3n natural, aunque debe tenerse en cuenta que SHA-256, SHA-384, y SHA-512 no est\u00e1n soportados en TLS, si bien MD5 goza de amplia aceptaci\u00f3n y debido a la naturaleza de las comunicaciones TLS, se considera v\u00e1lido ya que las HMACs est\u00e1n afectadas en mucha menor proporci\u00f3n, en t\u00e9rminos de colisi\u00f3n, que las funciones hashing subyacentes.<\/p>\n
Criterio de auditor\u00eda para el hashing<\/p>\n
HMAC-SHA-1 y HMAC-MD5 se consideran aceptables<\/p>\n
6. C\u00f3digo de autenticaci\u00f3n de mensajes (HMAC)<\/p>\n
Permite, mediante el secreto compartido, dotar a los mensajes de datos adicionales que permiten realizar verificaciones de autenticaci\u00f3n e integridad. Es frecuente hablar aqu\u00ed de HMAC, c\u00f3digos de autenticaci\u00f3n de mensajes obtenidos a trav\u00e9s de funciones hash. Los interesados pueden ojear el RFC 2104 para obtener m\u00e1s detalles, pero en s\u00edntesis, se trata de obtener un c\u00f3digo MAC mediante una funci\u00f3n hash y una clave secreta para proteger la integridad de los mensajes.<\/p>\n
Criterio de auditor\u00eda para HMACs<\/p>\n
HMAC depende de la funci\u00f3n hash escogida y la clave secreta compartida, luego estos ser\u00e1n los puntos a analizar<\/p>\n
Combinando todo lo anterior. El concepto de cipher suites<\/p>\n
Una vez hemos identificado los 5 elementos cruciales a considerar en la seguridad en comunicaciones a trav\u00e9s de Internet, surge la necesidad de combinarlos. Esta combinaci\u00f3n se denomina habitualmente como cipher suite, una nomenclatura en la que se une autenticaci\u00f3n, cifrado y c\u00f3digos de autenticaci\u00f3n de mensajes. Durante la negociaci\u00f3n, el servidor presenta al cliente la lista de suites disponibles, escogi\u00e9ndose la de mayor fortaleza entre las disponibles.<\/p>\n
As\u00ed, por ejemplo, la suite TLS_RSA_WITH_3DES_EDE_CBC_SHA implicar\u00e1 que tenemos TLS como protocolo, RSA para el establecimiento de la comunicaci\u00f3n, 3DES-EDE con modo de operaci\u00f3n CBC como mecanismo de cifrado y SHA-1 como motor para el c\u00e1lculo de la HMAC correspondiente. Las suites recomendadas por NIST est\u00e1n publicadas en la gu\u00eda, y son las siguientes:<\/p>\n
cipher suites<\/p>\n
Ejemplo 1: Una aplicaci\u00f3n web con una configuraci\u00f3n de seguridad SSL mejorable<\/p>\n
URL: https:\/\/wwws.tesoro.es
\nDescripci\u00f3n: P\u00e1gina para operativa del Tesoro P\u00fablico
\nComando: sslscan –no-failed wwws.tesoro.es:443<\/p>\n
Para obtener los detalles de la seguridad SSL de una manera r\u00e1pida, se puede emplear SSLscan. Me gusta esta herramienta porque presenta la informaci\u00f3n de una manera ordenada y especialmete \u00fatil para detectar r\u00e1pidamente la presencia de problemas.<\/p>\n
De la ejecuci\u00f3n sslscan –no-failed www.tesoro.es:443, que arrojar\u00e1 aquellas suites soportadas que no fallan o que no est\u00e1n expl\u00edcitamente rechazadas, obtenemos que:<\/p>\n
Accepted SSLv2 168 bits DES-CBC3-MD5
\nAccepted SSLv2 128 bits RC2-CBC-MD5
\nAccepted SSLv2 128 bits RC4-MD5
\nAccepted SSLv2 56 bits DES-CBC-MD5
\nAccepted SSLv2 40 bits EXP-RC2-CBC-MD5
\nAccepted SSLv2 40 bits EXP-RC4-MD5
\nAccepted SSLv3 168 bits DES-CBC3-SHA
\nAccepted SSLv3 128 bits RC4-SHA
\nAccepted SSLv3 128 bits RC4-MD5
\nAccepted SSLv3 56 bits DES-CBC-SHA
\nAccepted SSLv3 40 bits EXP-RC2-CBC-MD5
\nAccepted SSLv3 40 bits EXP-RC4-MD5
\nAccepted TLSv1 168 bits DES-CBC3-SHA
\nAccepted TLSv1 128 bits RC4-SHA
\nAccepted TLSv1 128 bits RC4-MD5
\nAccepted TLSv1 56 bits DES-CBC-SHA
\nAccepted TLSv1 40 bits EXP-RC2-CBC-MD5
\nAccepted TLSv1 40 bits EXP-RC4-MD5<\/p>\n
Los cifrados preferidos del servidor<\/p>\n
SSLv2 168 bits DES-CBC3-MD5
\nSSLv3 128 bits RC4-MD5
\nTLSv1 128 bits RC4-MD5<\/p>\n
Destacan:<\/p>\n
La presencia de SSLv2 como cifrado preferido del servidor y otros dos m\u00e9todos que, aun siendo aceptables, no son los m\u00e1s aconsejables en un servicio de este tipo
\nM\u00faltiples 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)
\nEstablecimiento de comunicaci\u00f3n con RSA 1024, siendo 2048 m\u00e1s recomendable para entornos transaccionales<\/p>\n
Ejemplo: Una aplicaci\u00f3n web con una buena configuraci\u00f3n seguridad SSL<\/p>\n
URL: https:\/\/www.twitter.com
\nDescripci\u00f3n: Versi\u00f3n HTTPS de Twitter
\nComando: sslscan –no-failed www.twitter.com:443<\/p>\n
Accepted SSLv3 256 bits AES256-SHA
\nAccepted SSLv3 168 bits DES-CBC3-SHA
\nAccepted SSLv3 128 bits AES128-SHA
\nAccepted SSLv3 128 bits RC4-SHA
\nAccepted SSLv3 128 bits RC4-MD5
\nAccepted TLSv1 256 bits AES256-SHA
\nAccepted TLSv1 168 bits DES-CBC3-SHA
\nAccepted TLSv1 128 bits AES128-SHA
\nAccepted TLSv1 128 bits RC4-SHA
\nAccepted TLSv1 128 bits RC4-MD5<\/p>\n
Los cifrados preferidos del servidor<\/p>\n
SSLv3 256 bits AES256-SHA
\nTLSv1 256 bits AES256-SHA<\/p>\n
Destacan:<\/p>\n
Ni rastro SSLv2 ni de mecanismos de cifrado d\u00e9biles o de media calidad. Suites reducidas en n\u00famero
\nExcelentes suites marcadas como preferidas, ambas de extraordinaria calidad criptogr\u00e1fica
\nEstablecimiento de comunicaci\u00f3n con RSA 2048, sobrepasando el m\u00ednimo exigido para un entorno de autenticaci\u00f3n<\/p>\n
Por \u00faltimo … cuidado al recomendar. Navegadores y soporte TLS<\/p>\n
Firefox, de momento, s\u00f3lo soporta TLS 1.0. No soporta TLS 1.1 ni TLS 1.2
\nTLS 1.2 s\u00f3lo se soporta en Internet Explorer 8 bajo Windows 7 o Windows Server 2008 R2
\nSafari soporta TLS, pero Apple no ha divulgado oficialmente qu\u00e9 versi\u00f3n soporta
\nOpera soporta TLS 1.2<\/p>\n