Configurar TLS: 5 errores comunes que se deben evitar

0
67

Un certificado Transport Layer Security (TLS) es parte vital de un desayuno de seguridad equilibrado, pero millones de organizaciones siguen alimentándose muy mal.

Usted pensaría que configurar y desplegar un certificado TLS de forma segura sería una cosa fácil, pero un vistazo rápido a Censys o Shodan revela una cantidad gigantesca de certificados inseguros de TLS, incluidos algunos de organizaciones que realmente deberían haberlo sabido.

Los certificados TLS protegen la confidencialidad e integridad del tráfico web, el correo electrónico y un número creciente de otros servicios, como DNS. Si bien el sistema X.509 puede ser criticado por estar fundamentalmente defectuoso, sigue siendo una mitigación importante y simple que no debe ignorarse, incluso si no es una solución mágica que, de la nada, hace que todo esté asombrosamente seguro.

Aquí hay cinco consejos para mantener feliz al duende TLS.

1. Use claves TLS más largas
La factorización de los picos de RSA, que alcanzan niveles tan pequeños como 1024 bits, es un problema resuelto, lo que significa que un atacante puede descargar su clave pública publicada, forzar la llave privada y descifrar su tráfico, o incluso suplantar su servidor. La solución: utilizar llaves TLS más largas.

Una llave de 2048 bits es actualmente el estándar de la industria, y no debería usar nada menos. Usar un RSA de 3072 bits o 4096 bits no es una locura para las páginas web que no tienen requisitos de rendimiento increíblemente rápidos. El aumento de la longitud de la llave RSA viene con un pequeño impacto en el rendimiento que puede o no ser perceptible para sus usuarios.

Si bien garantizar que la longitud mínima de la llave RSA sea fundamental para la seguridad del certificado TLS, existen tantas formas más de atacar al TLS que la longitud de la llave es solo el comienzo del viaje, no el final.

2. Retire TLS 1 y TLS 1.1, si es posible
Al igual que SSL v2 y SSL v3, que deben ser condenados con extremo prejuicio, TLS v1 ya no se considera una mejor práctica aceptable -incluso PCI DSS exigió que las páginas web en cumplimiento con PCI removieran el soporte de TLS v1 el año pasado, e instó a los comerciantes a deshabilitar TLS v1.1 también.

En una sección titulada «¿Cuál es el riesgo de usar SSL/TLS inicial?”, las personas en PCI escriben que «existen muchas vulnerabilidades graves en SSL y TLS inicial que, de no ser enfrentadas, ponen a las organizaciones en riesgo de ser irrumpidas. La generalizada POODLE y los exploits BEAST son solo un par de ejemplos de cómo los atacantes han aprovechado las debilidades de SSL y TLS para afectar a las organizaciones”.

La gente de seguridad sabe que PCI/DSS no es exactamente un consejo de seguridad de vanguardia, sino una línea base de cumplimiento mínima. A menos que su empresa tenga la necesidad de admitir muchos dispositivos muy antiguos, es una buena idea eliminar el soporte para TLS v1 y TLS v1.1 lo antes posible.

La compatibilidad con TLS 1.3 aún es nueva, pero ofrece mayor seguridad y mejoras de rendimiento. La nueva especificación se finalizó en agosto del 2018, y la adopción ha sido lenta hasta ahora. La oferta de TLS 1.3 no causa daños conocidos y hará un downgrade a TLS 1.2 si el cliente no soporta al protocolo más nuevo.

3. Elimine el soporte para las antiguas suites de cifrado, si es posible
Tantos ataques de downgrade, tan poco tiempo. POODLE, FREAK, Logjam -la lista sigue y sigue. Para soportar dispositivos más antiguos, muchas implementaciones de TLS soportaron a la denominada «encriptación de exportación” de la década de los noventa -encriptación deliberadamente identificada por la National Security Agency (NSA) de Estados Unidos, que establece límites en la solidez de la encriptación que podría venderse en el extranjero. De acuerdo con una búsqueda de Censys, engañar a un servidor web para que piense que un cliente solo soporta suites de cifrado defectuosas y antiguas funcionó ampliamente hasta hace poco… y sigue afectando a millones de páginas web.

Tenga cuidado de habilitar solo cifrados seguros, y si debe tolerar cifrados más débiles, compare la ganancia de disponibilidad para un pequeño porcentaje de usuarios, frente a la posible pérdida de confidencialidad e integridad que afectará a todos sus usuarios.

Para una lista de suites de cifrado que su certificado TLS soporta actualmente, y un análisis de cuáles se consideran seguros, la prueba online de Qualys SSL Labs es un buen punto de partida.

4. Utilizar tiempos de validez más cortos
La forma más sencilla de afectar a un certificado TLS correctamente configurado e implementado es hackeandoel servidor y robando la clave privada. La rotación regular de las claves garantiza que el robo de claves no sea el final del juego, y compartimenta el daño a una ventana máxima de vulnerabilidad. Los expertos recomiendan un máximo de 60 a 90 días, y Let’s Encrypt refuerza un máximo de 90 días.

Sin embargo, el estándar de la industria todavía permite períodos de validez de llave de hasta dos años (ochocientos veinticinco días), reducidos a partir del 2018, de un máximo que anteriormente alcanzaba tres años. No haga esto. La rotación regular de llaves de treinta días no sería una sugerencia descabellada a estas alturas. Forzar a los atacantes a mantener la persistencia, o hackear regularmente su servidor para robar una clave nueva, aumenta la probabilidad de que usted los atrape. Si bien puede ser imposible defenderse contra los autores de amenazas más peligrosas que existen, puede y debe hacer su vida lo más difícil posible.

5. Evite los certificados de comodín en múltiples dispositivos
Hackear un servidor para robar una clave TLS es muy fácil si esa clave privada se implementa en docenas de dispositivos, incluyendo un servidor web, un servidor de correo electrónico, una fotocopiadora, una impresora, o algún dispositivo de Internet de las cosas (IoT, por sus siglas en inglés) aleatorio, por ejemplo. Ahora la superficie de ataque es tan gigantesca que un atacante solo necesita identificar el dispositivo más débil y hackear su fotocopiadora en lugar de su servidor web.

Mientras más copias de la clave privada haya, más fácil será para un atacante robar la clave y descifrar todas las cosas. Entonces, no lo haga. Siempre que sea posible, las claves privadas deben ser exclusivas para cada dispositivo.

¿Cree que su organización es inmune? Incluso GCHQ, la agencia de policía secreta del Reino Unido, logró arruinar una implementación de TLS comodín.

Las malas prácticas de implementación de TLS revelan mucho sobre su organización a los atacantes, que huelen carne fresca, pero también a los reguladores y las compañías de seguros de ciberseguridad, que analizan el rango completo de IPv4 todas las semanas. Si no puede darse la molestia de implementar sus certificados TLS correctamente, ¿qué aspecto tiene el resto de su infraestructura? Muchas personas están mirando, algunas de ellas no son tan amables. Proyecte valentía.

JM Porup, CSOonline.com