Como escribimos en el Informe de problemas y disponibilidad de redes interconectadas 2018-2019 a principios de este año, la llegada de TLS 1.3 es inevitable. Hace algún tiempo implementamos con éxito la versión 1.3 del protocolo de Seguridad de la capa de transporte. Después de recopilar y analizar los datos, ahora estamos listos para resaltar las partes más emocionantes de esta transición.Como escribieron los presidentes del grupo de trabajo de IETF TLS
en el artículo :
"En resumen, TLS 1.3 está preparado para proporcionar una base para una Internet más segura y eficiente durante los próximos 20 años y más".
TLS 1.3 ha llegado después de 10 años de desarrollo. Qrator Labs, así como la industria de TI en general, observaron de cerca el proceso de desarrollo desde el borrador inicial a través de cada una de las 28 versiones mientras maduraba un protocolo equilibrado y manejable que estamos listos para brindar soporte en 2019. El soporte ya es evidente entre los mercado, y queremos mantener el ritmo en la implementación de este protocolo de seguridad robusto y probado.
Eric Rescorla, el único autor de TLS 1.3 y el CTO de Firefox,
le dijo a The Register que :
"Es un reemplazo directo para TLS 1.2, utiliza las mismas claves y certificados, y los clientes y servidores pueden negociar automáticamente TLS 1.3 cuando ambos lo admiten", dijo. "Ya existe una buena compatibilidad con la biblioteca, y Chrome y Firefox tienen TLS 1.3 activado de forma predeterminada".
Hay una lista de implementaciones actuales de TLS 1.3 en GitHub disponible para todos los que busquen la biblioteca que mejor se adapte:
https://github.com/tlswg/tls13-spec/wiki/Implementations . Está claro que la adopción del protocolo actualizado sería, y ya es, rápida y generalizada, ya que ahora todos entienden cuán fundamental es el cifrado en el mundo moderno.
¿Qué ha cambiado en comparación con TLS 1.2?
Del
artículo de Internet Society :
“¿Cómo está mejorando TLS 1.3 las cosas?
TLS 1.3 ofrece algunas ventajas técnicas, como un protocolo de enlace simplificado para establecer conexiones seguras y permitir a los clientes reanudar las sesiones con los servidores más rápidamente. Eso debería reducir la latencia de configuración y la cantidad de conexiones fallidas en enlaces débiles que a menudo se usan como justificación para mantener conexiones solo HTTP.
Igual de importante, también elimina la compatibilidad con varios algoritmos de cifrado y hashing obsoletos e inseguros que actualmente se permiten (aunque ya no se recomiendan) para usarse con versiones anteriores de TLS, incluidos SHA-1, MD5, DES, 3DES y AES- CBC, al tiempo que agrega soporte para las nuevas suites de cifrado. Otras mejoras incluyen más elementos encriptados del apretón de manos (por ejemplo, el intercambio de información del certificado ahora está encriptado) para reducir sugerencias a posibles espías, así como mejoras para reenviar el secreto cuando se utilizan modos de intercambio de claves particulares para que las comunicaciones en un momento dado en el tiempo debería permanecer seguro incluso si los algoritmos utilizados para cifrarlos se ven comprometidos en el futuro ".
DDoS y desarrollo de protocolos modernos
Como ya habrá escuchado, hubo
tensiones significativas en el grupo de trabajo IETF TLS durante el desarrollo del protocolo, e
incluso después de eso . Es evidente ahora que las empresas individuales (incluidas las instituciones financieras) tendrían que cambiar la forma en que se construye la seguridad de su red para adaptarse al
secreto directo perfecto ahora incorporado.
Las razones por las cuales esto podría ser requerido se describen en un
documento escrito por Steve Fenter . El borrador de 20 páginas menciona varios casos de uso en los que una empresa puede desear descifrar el tráfico fuera de banda (que PFS no le permite hacer), incluido el monitoreo de fraudes, los requisitos reglamentarios y la protección DDoS de capa 7.
Si bien definitivamente no tenemos derecho a hablar de los requisitos reglamentarios, nuestro propio producto de mitigación DDoS de capa 7 (incluida la solución que
no requiere que un cliente nos revele datos confidenciales) se construyó en 2012 con PFS en mente desde inicio, y nuestros clientes no necesitaban cambios en su infraestructura después de la actualización de la versión TLS del lado del servidor.
Sin embargo, una preocupación con respecto al desarrollo de las suites y características de protocolo de próxima generación es que generalmente depende en gran medida de la investigación académica, y el estado de eso para la industria de mitigación de DDoS es bastante pobre.
La Sección 4.4 del borrador de IETF “Capacidad de administración de QUIC” , que es parte del futuro conjunto de protocolos QUIC, podría verse como un ejemplo perfecto de eso: establece que “las prácticas actuales en la detección y mitigación de [ataques DDoS] generalmente implican pasividad medición utilizando datos de flujo de red ", siendo este último muy raramente un caso en entornos empresariales de la vida real (y solo en parte para configuraciones de ISP), y de ninguna manera difícilmente es un" caso general "en la práctica, pero definitivamente es un caso general en trabajos de investigación académica que, la mayoría de las veces, no están respaldados por implementaciones adecuadas y pruebas del mundo real contra toda la gama de posibles ataques DDoS, incluidos los de la capa de aplicación (que, debido al progreso en el despliegue mundial de TLS, obviamente podría nunca más se maneje con ninguna medida pasiva).
Del mismo modo, aún no sabemos cómo los fabricantes de hardware de mitigación DDoS se adaptarían a la realidad TLS 1.3. Debido a la complejidad técnica del soporte de protocolo fuera de banda, podría llevarles algún tiempo.
Establecer una tendencia de investigación académica adecuada es un desafío para los proveedores de mitigación de DDoS en 2019. Un área donde podría hacerse es el
grupo de investigación SMART dentro de IRTF donde los investigadores podrían colaborar con la industria para refinar su conocimiento del área problemática y las instrucciones de investigación. Damos una calurosa bienvenida a todos los investigadores que quieran contactarnos con preguntas o sugerencias en ese grupo de investigación, así como por correo electrónico:
rnd@qrator.net .