Certificados SSL realmente seguros (SHA-2)

En 2015 la mayor parte de los usuarios, de una manera u otra, somos conscientes de la importancia de la seguridad cuando se utiliza un medio como Internet. Todos hemos sufrido alguna vez algún ataque en nuestras carnes (robo de contraseña de correo, servidor web hackeado, malware instalado, infección de virus, víctimas de phising, red WIFI crackeada…) y sin duda la experiencia ha sido desagradable. Internet está cada día más presente en nuestras vidas, por lo que es fundamental proteger bien nuestros activos y servicios de los ciberdelincuentes, al igual que nos preocupamos de proteger las entradas de nuestras viviendas y comercios con puertas y cerraduras seguras, cámaras de seguridad, incluso accesos biométricos.

HTTPS certificado SSL

CC by Sean MacEntee

Uno de los elementos que ayudan en este complejo proceso de la seguridad son los certificados SSL, que permiten cifrar las comunicaciones que establecemos con los diferentes servicios de los que hacemos uso. Los certificados SSL establecen un canal seguro entre el emisor y el receptor que garantiza que la información intercambiada no se vea comprometida, además de garantizar a quien pertenece el certificado, y por consiguiente el servicio al que se accede.

Muchos son los sitios que utilizan certificados SSL, pero pocos son los que utilizan certificados SSL realmente seguros a día de hoy. Los certificados SSL son firmados utilizando un hash de una única dirección, para garantizar la integridad del mismo (y garantizar que el certificado no se ha modificado). La mayor parte de los certificados existentes en internet (e intranets) utilizan SHA-1 y desde hace años se ha venido avisando que el hash SHA-1 es inseguro, debido a vulnerabilidades matemáticas, ya que existen colisiones que permiten crackear el protocolo 2000 veces más rápido de lo esperado.

El predecesor a SHA-1, MD5, es vulnerable a ataques que permiten crear certificados falsos en 1 solo día.

El papel de los navegadores web

Por ello, los navegadores nos irán avisando de ello, mediante un triángulo amarillo en el candado de las URL, lo que generará desconfianza en los usuarios, si los certificados no están actualizados.

Triangulo amarillo candado warning SSL SHA1

Triangulo amarillo candado warning SSL SHA1

La NIST recomienda que los certificados firmados con SHA-1 no deberían ser considerados de confianza a partir del 1 de Enero de 2015.

Sin embargo, debido a la gran cantidad de sitios web con SHA-1, los principales navegadores (Firefox, Chrome y Explorer) no van a mostrar errores hasta el 1 de Enero de 2016 (siempre y cuando los navegadores estén actualizados) y los considerarán inseguros a partir del 1 de Enero de 2017.

Veamos varios ejemplos de webs potencialmente inseguras a día de hoy:

www.google.com y www.facebook.com utilizan SHA1

www.google.com y www.facebook.com utilizan SHA1

Puedes jugar con  la web https://shaaaaaaaaaaaaa.com/ (herramienta liberada en github) para comprobar si tu sitio web utiliza un certificado SSL firmado mediante SHA-1. Si quieres información más detallada, las siguientes páginas te dan información muy detallada, no solo de este problema sino de la calidad en general de tu conexión SSL/TLS:

La razón para que estos gigantes de Internet aun soporten SHA-1 es porque quieren mantener la compatibilidad con navegadores muy antiguos, aunque Google ya ha avisado que lo renovará a finales de año. Mientras tanto, utilizan certificados que expiran en 3 meses, para así reducir la posibilidad de suplantación. El resto de clientes del resto de servicios (SMTPS, IMAPS, POPS, SFTP, LDAPS, MYSQLS…) veremos si reaccionan y generan avisos (aunque es probable que no y dependerá de los administradores hacerlo).

¿En qué consiste el ataque y en que medida nos afecta?

Un ataque de colisión habitualmente funciona de la siguiente manera:

  1. Gorka crea 2 documentos diferentes A y B, que tienen el mismo valor de hash (colisión)
  2. Gorka envía el documento A a Laura, quien está de acuerdo con lo que dice el documento, firma su hash y se lo envía de vuelta.
  3. Gorka copia la firma enviada por Laura del documento A al documento B.
  4. Gorka envía el documento B a Bea, indicando que Laura ha firmado el documento. Como la firma digital coincide con el hash del documento, el software de Bea no es capaz de detectar la modificación

Esto permitiría crear una CA intermedia firmada por una ROOT CA con la que expedir certificados que cualquier navegador daría por válido, por lo que todos los sitios web y otros servicios protegidos con un certificado SSL con firma SHA-1 son vulnerables a dicho ataque.

Todos los certificados SSL deberán ser re-generados correctamente con SHA256. Esto requiere cambiar casi todos los certificados SSL del mundo:

SHA1 vs SHA2 netcraft

SHA1 vs SHA2 netcraft.com (mayo ’14)

Según el experto de seguridad B. Schneier el coste de calcular colisiones en SHA-1 será de 610.000€ en 2015, 150.000€ en 2018, y 37.000€ en 2021, importes al alcance de organizaciones criminales u organizaciones con sistemas de gran capacidad de cálculo.

¿Cómo podemos solventar este problema?

La manera de solventarlo (al igual que cuando se descartó MD5 en favor de SHA-1), es utilizar un algoritmo de hash seguro, con un número de bits suficientemente grande para considerar que no se pueden calcular colisiones, como SHA-2 o SHA-3 (en un futuro), en nuestros certificados SSL (y en aquellos de terceros que usemos). Esto requiere re-generar todos los certificados SSL.

Desde un sistema Linux, BSD, Mac o Windows, implementar el soporte para firma segura a la hora de generar un CSR (solicitud de firma de certificado) es muy sencillo gracias a las librerías de software libre OpenSSL, tan solo tenemos que añadir la opción -sha256 o -sha512 a nuestro comando habitual y enviárselo a la Autoridad Certificadora correspondiente:

Algoritmo 256bits:

openssl req -new -sha256 -key clave-privada.key -out tu-dominio.csr

Algoritmo 512 bits:

openssl req -new -sha512 -key clave-privada.key -out tu-dominio.csr

Algunos paneles de hosting como Cpanel ya lo han implementado por defecto y todos los CSR incluirán una longitud de 256 bits. Otros, como Parallels, aun no, pero te informan como hacerlo.

Para que el comando openssl utilice SHA256 por defecto, y así evitar tenerlo que especificar como opción en cada comando, en el archivo de configuración (/etc/ssl/openssl.cnf) es necesario indicar:
default_md = sha256

Nota: no confundir este término con el de longitud de clave (2048 o 4096) o el tamaño de la clave de cifrado simétrico intercambiada durante la sesión (también 256 o 512).

Esto es realmente importante para los certificados autofirmados, ya que las autoridades de certificación oficiales (GeoTrust, Verisign, Comodo…) no permitirán solicitudes con SHA1 y con ello prevendrán a los usuarios y administradores que desconozcan esta situación. Sin embargo, en los certificados autofirmados la seguridad dependerá de nosotros mismos.

Importante: No te olvides también de cambiar los certificados intermedios en tu servidor:

No te preocupes si los certificados raíz son SHA-1, ya que que su integridad se verifica sin la firma digital.

Conclusiones

Actualiza todos tus certificados lo antes posible, mejor antes del 31 de diciembre de 2015. Desde ya se consideran que son inseguros si utilizas SHA-1. Si lo solicitas, la mayor parte de las autoridades de certificación emitirán un nuevo certificado sin coste adicional.

La mejor solución a mi entender es que openssl y otras herramientas utilizasen SHA256 por defecto (a pesar de que algunos sistemas antiguos no reconocen estos certificados, como Windows XP con SP2 o inferior, Windows Server 2003 SP1 o inferior, Mac OS X 10.4 o inferior o Android 2.2 o inferior). Mientras tanto, tendremos que hacer nosotros el trabajo manualmente.

El anterior cambio (de MD5 a SHA-1) tardó muchos años en llevarse a cabo en Internet debido a los millones de sitios web existentes (muchos de ellos sin actualizaciones ni mantenimiento). Hoy en día, aun hay certificados vigentes con MD5. Esta vez también se espera que el cambio sea lento. Esperemos que el aviso en los navegadores ayude a acelerar el proceso.

Si necesitas ayuda, soporte o contratar un certificado SSL seguro, desde Irontec estaremos encantados de ayudarte. Disponemos de certificados SSL estándar, premium, EV y wildcard a precios muy competitivos. Si te preocupa la seguridad de tu sitio web o servicio expuesto a internet, ponte en contacto con nosotros.

 



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre Iker Sagasti Marquina

Iker Sagasti es CEO de Irontec, con más de 15 años de experiencia trabajando con Software Libre. Ingeniero de Telecomunicaciones, aficionado a la fotografía y viajero empedernido. Cuenta los días para cumplir el sueño de trabajar en chanclas delante de una playa con una cerveza fría en mano.

1 Comentario

¿Por qué no comentas tú también?

Queremos tu opinión :)