El trabajo en la nueva versión del protocolo TLS 1.3 está casi completo. Después de cuatro años de discusión en marzo de 2018, el IETF aprobó la
versión 28 del borrador como un estándar propuesto, por lo que debería ser el último antes de adoptar las especificaciones finales.
TLS 1.3 acelera el proceso de establecer una conexión segura en aproximadamente la mitad al combinar varios pasos en este punto. Además, implementa un régimen de secreto directo perfecto a través de las claves efímeras (EC) DH. Este modo garantiza la protección de las claves de sesión incluso en caso de compromiso de claves a largo plazo.
Se han implementado muchas otras mejoras, incluido el soporte para el cifrado de flujo ChaCha20, los algoritmos de firma digital Ed25519 y Ed448, los protocolos de intercambio de claves x25519 y x448, etc. Se eliminó el soporte para funciones hash obsoletas MD5 y SHA-224, curvas elípticas débiles y poco utilizadas
Pero lo más interesante es la nueva idea que se está
discutiendo en el IETF . Los expertos de Google sugieren generar periódicamente al azar una nueva versión del protocolo TLS con pequeños cambios. La idea es que las actualizaciones frecuentes serán un antídoto para la osificación peligrosa.
¿Cuál es este problema?
La llamada "osificación" es una situación en la que los desarrolladores de protocolos de repente se dan cuenta de que es difícil introducir mejoras debido a la distribución generalizada de la versión anterior, que por alguna razón conviene a los usuarios. En realidad, la versión anterior ya no cumple con los requisitos de seguridad modernos y las nuevas especificaciones, pero no se puede implementar de facto.
Se
cree que los llamados nodos intermedios, es decir, los proveedores de soluciones en el campo de la "seguridad", se convirtieron en el principal "freno" específicamente con la implementación de TLS 1.3. Aconsejan a sus clientes que prescriban
reglas de firewall específicas con escaneo de certificados cuando se dan la mano con TLS. En la nueva versión del estándar, los
certificados SSL están encriptados, por lo que los intermediarios ya no podrán escanearlos.
¿Cómo la actualización constante resolverá el problema de la osificación del protocolo?
La actualización continua cada seis semanas es un patrón familiar del navegador Chrome. En esta situación, los "artistas intérpretes o ejecutantes" se ven
obligados a cumplir con las especificaciones, ya que una implementación incompatible no funcionará para una gran proporción de usuarios.
En la lista de correo de IETF, esta idea fue
sugerida por David Benjamin del proyecto Chromium. Él escribe que TLS 1.3 es un protocolo extensible que es compatible con versiones anteriores de TLS 1.2. Se puede implementar gradualmente, actualizando las implementaciones actuales de TLS 1.2. Y aquí hay problemas. Numerosos servidores incompatibles no podrán establecer una conexión en la etapa TLS 1.3 ClientHello, por lo que deberá retroceder para establecer una conexión utilizando la versión de protocolo compatible.
David Benjamin plantea la idea de cómo evitar este problema en el futuro. Discutiendo medidas preventivas, menciona
invariantes de protocolo que se enumeran en la cláusula 9.3 de las especificaciones. Todos los puntos finales y nodos intermedios
deben cumplir con los invariantes descritos. En particular, los nuevos clientes y nuevos servidores no tienen derecho a reducir el nivel de parámetros a la versión anterior. Del mismo modo, los nodos intermedios no tienen derecho a hacer esto cuando transfieren la conexión entre el cliente actualizado y el servidor y no pueden afectar el protocolo de enlace. Sin embargo, dada la velocidad de actualización desigual, los clientes y servidores actualizados pueden admitir el establecimiento de la comunicación utilizando el protocolo anterior, pero solo de la manera correcta descrita en la cláusula 9.3.
Pero la práctica muestra que no es suficiente describir el comportamiento requerido en las especificaciones. ¿Cómo
obligar a los nodos intermedios a cumplir la regla clave del procesamiento de ClientHello para ignorar los parámetros no reconocidos? Para esto, se propone el método
GREASE .
GRASA: antídoto contra la osificación
GREASE (Generar extensiones aleatorias y mantener la extensibilidad) es un método para generar extensiones
aleatorias para TLS y el lanzamiento constante de nuevas versiones del protocolo. David Benjamin propone establecer un ciclo estándar de lanzamiento de seis semanas, que coincidirá con el lanzamiento de nuevas versiones de Chrome.
El lanzamiento de tal "basura" en grandes cantidades obligará a los servidores a cumplir con la regla clave del procesamiento de ClientHello para ignorar los parámetros no reconocidos. También se extenderá a los nodos intermedios. Para que no interfieran en la comunicación entre el cliente y el servidor, la regla clave para ellos es esta: si no envió una solicitud de ClientHello, entonces no tiene derecho a procesar la respuesta. Del mismo modo, el ecosistema debería inundarse con una gran cantidad de tales respuestas.
"En resumen, planeamos estampar regularmente nuevas versiones de TLS (y probablemente otros parámetros sensibles como las extensiones)", dice Benjamin, aparentemente expresando el punto de vista de Google. - aproximadamente cada seis semanas, de acuerdo con el calendario de lanzamiento de Chrome. Luego, Chrome, los servidores de Google y todos los demás que quieran participar admitirán dos (o más) versiones de TLS 1.3: el estándar estable 0x0304 y la versión alternativa temporal. Cada seis semanas, seleccionamos aleatoriamente un nuevo punto de código. En todos los demás aspectos, estas versiones son idénticas a la 1.3, con la posible excepción de detalles menores para separar claves y realizar cambios sintácticos permitidos. El objetivo es allanar el camino para futuras versiones de TLS imitándolos (borrador negativo) ”.
Tal esquema tiene ciertos riesgos, incluyendo colisiones de puntos de código. Además, se deben desarrollar precauciones, porque la tarea es mantener y mantener la extensibilidad de TLS, y no interferir con el desarrollo del protocolo. De las medidas de precaución:
- Documentación detallada de todos los puntos de código (al calcular un punto en un mes y medio, serán suficientes durante más de 7000 años).
- Evitar colisiones proactivas: rechazar números que el IETF puede elegir.
- BoringSSL no habilitará esta opción por defecto. Se habilitará solo donde se pueda deshabilitar: en servidores y en el navegador. En realidad, muy probablemente, en cada momento en el tiempo, solo se usarán los últimos puntos de código. Debido a que están cambiando rápidamente, el ecosistema no debe unirse a ninguna expansión temporal de este tipo, y las implementaciones seguirán siendo compatibles entre sí.
- Si por alguna razón el método no funciona, el experimento se puede detener en cualquier momento.
La idea es interesante, y si Google comienza a actuar de esta manera, realmente puede salvar al ecosistema de una "osificación" peligrosa debido a los proveedores de soluciones en el campo de la "seguridad" y otros sistemas corporativos específicos. Un representante de Cloudflare
apoyó esta propuesta. En cualquier caso, dijo, al menos hay que hacer algo para evitar el problema que encontramos al intentar implementar TLS 1.3. Otro miembro del grupo de trabajo del IETF lo
calificó como una "idea fantástica" y sugirió que Google creara una página wiki que describa los puntos de código que usa o planea usar en el futuro.
