Texto｜Zeng Ke (nombre de la flor: Yi Si)
El ingeniero senior
de Ant Group es responsable de la construcción de la capa de acceso de Ant Group. La dirección principal es el diseño y la optimización de protocolos de red de seguridad de alto rendimiento.
Este artículo tiene 10924 palabras, se lee 20 minutos
PARTE 1 Introducción
Del artículo anterior "HTTP/3 en profundidad (1) | Mirando la evolución del protocolo desde el establecimiento y cierre de enlaces QUIC" , aprendimos de la breve introducción a QUIC que la optimización de QUIC es en gran parte una optimización basada sobre el proceso TLS, que también muestra la importancia de TLS para QUIC, por lo que hoy hablaremos sobre QUIC-TLS. Para expresar la menor ambigüedad posible, primero estandarizamos el significado de cada término en el artículo.
Dado que los dos términos SSL y TLS se han mencionado en este artículo, también podríamos revisar brevemente el historial de desarrollo de los protocolos de seguridad, que no solo puede ayudarnos a aclarar la relación entre los dos términos, sino también a comprender la evolución de esta tecnologia Hay un breve concepto.
El propio protocolo SSL (Secure Sockets Layer) es un conjunto de protocolos diseñados por Netscape en 1994 para garantizar la seguridad de la transmisión de datos en Internet. Este protocolo se usaba ampliamente en los principales navegadores en ese momento, pero la seguridad de las primeras versiones del protocolo SSL era muy preocupante. Los cambios iniciales fueron muy frecuentes. De 1994 a 1995, tres versiones principales se iteraron continuamente, mientras que ahora todos está más familiarizado con SSLv3.0. Desafortunadamente, SSLv3.0 no ha escapado a la fatalidad del cambio. Debido a la iteración de la potencia informática del hardware, una gran cantidad de algoritmos de cifrado ampliamente utilizados en SSLv3.0 ya no son seguros y el proceso de interacción del protocolo también es inseguro. En 1999, el IETF participó formalmente en el diseño y desarrollo de protocolos de seguridad y lanzó la primera versión del protocolo TLS (Transport Layer Security) , TLS1. .1, y lanzó TLS1.2 nuevamente en 2008. Ambas versiones están dirigidas a mejorando la seguridad de algunos detalles en el proceso de interacción de apretón de manos De hecho, el proceso de apretón de manos no ha cambiado mucho.
Hasta 2013, cuando Google lanzó gquic, también lanzó su proceso de interacción seguro diseñado quic-crypto.quic-crypto fue una gran innovación en el proceso de interacción y se convirtió en el predecesor de TLS1.3. TLS1.3 debería llamarse TLS2.0 en cierto sentido, porque su innovación es muy fuerte, por supuesto, esto también lleva a un proceso de estandarización muy largo.La estandarización de TLS1.3 ha durado 4 años, y no fue hasta 2018. Conviértase formalmente en un RFC. TLS 1.3 también se ha convertido en la base de la tecnología de interacción segura de IETF-QUIC, por lo que esta línea de tiempo también se mezcla con el proceso de diseño de QUIC-TLS. Expliquemos brevemente:
Figura 1. Una breve historia del desarrollo de TLS
Por supuesto, la evolución de DTLS y otras tecnologías de seguridad relacionadas también se integran en esta línea de tiempo.Debido a limitaciones de espacio, no se incluye aquí por el momento. Habiendo dicho tantas tonterías, ahora estandaricemos formalmente nuestros sustantivos:
[SSL, TLS] : en este artículo, todos se refieren a protocolos de transmisión segura, y los artículos posteriores solo usarán TLS como sinónimo de tecnologías relacionadas.
[QUIC-crypto] : el proceso de negociación utilizado en Google quic, que no se analiza específicamente en este artículo
[QUIC-TLS] : este artículo hace referencia al proceso de interacción segura utilizado por IETF-QUIC, es decir, el proceso estandarizado en RFC9001, que también es el centro de esta descripción detallada
[PTO] : El nombre completo es Probe Timeout, el cual está definido en RFC9002, y se deja para el próximo artículo analizarlo en detalle, en este artículo se entiende como el tiempo fijado por un extremo de comunicación para la retransmisión del timeout de el mensaje.
[DTLS] : El nombre completo es Datagram Transport Layer Security, es decir, el protocolo TLS orientado a mensajes, por limitaciones de espacio este artículo no lo analiza en detalle, existiendo muchos diseños similares a QUIC-TLS en DTLS. Los estudiantes interesados pueden consultar RFC9147
"hacer que la infraestructura sea aburrida" es el eslogan de Google, y BoringSSL, un producto de código abierto, es su acción en el campo de la comunicación segura. Dado que el título del artículo se llama "SSL que no es tan aburrido", además de rozar con la famoso BoringSSL y OpenSSL Además de la popularidad del proyecto de código abierto SSL, también quiero crear un poco de suspenso para el artículo: Aburrido a menudo significa que las tecnologías relacionadas son simples y fáciles de usar hasta el punto de escandaloso, y qué problemas ¿Encontró QUIC para hacer que el protocolo TLS relativamente maduro lo usara?¿No más aburrido?
El resto de este artículo también se centrará en este tema y analizará los aspectos interesantes del diseño QUIC-TLS .
PARTE 2 Una breve mirada a TLS
De acuerdo con la idea de lo más superficial a lo más profundo, antes de comenzar a presentar QUIC-TLS, analicemos primero TLS, que también es muy útil para nuestra comprensión de QUIC-TLS más adelante.
El protocolo TLS resuelve varias cuestiones filosóficas hasta cierto punto:
¿Quién eres? ¿Cómo demuestras que eres tú?
Por supuesto, las respuestas a estas preguntas no son suficientes para garantizar la seguridad general...
1. También necesitamos una tecnología para garantizar que el intermediario no pueda obtener nuestros datos , que es la "tecnología de cifrado simétrico" con la que estamos relativamente familiarizados , como AES, SM4 y otras tecnologías de cifrado;
2. Para que los datos cifrados también puedan probar la identidad del extremo de la comunicación , presentamos el "Cifrado AEAD es el modo de autenticación" ;
3. Para poder negociar esta clave de cifrado simétrica , TLS introduce una "tecnología de intercambio de claves asimétricas" , típicamente como ECDHE, RSA y otros algoritmos de intercambio de claves;
4. Con el fin de unificar la gestión de identidades y llevar identidades de manera efectiva , TLS presenta la "tecnología de certificado digital" , que incluye todo el sistema de clave pública pki y el estándar de certificado digital X509;
5. Para evitar que se alteren los datos , TLS introduce "tecnología de firma digital" , generalmente como ECDSA, RSA y otros algoritmos de firma;
6. Para la independencia de las claves de cifrado en cada etapa y la simplicidad del proceso de firma , TLS presenta el "algoritmo Hash" , típicamente como la serie de algoritmos SHA.
Los diversos mecanismos mencionados anteriormente se resumen en protocolos de dos partes en todo el protocolo TLS:
La primera capa es el protocolo Handshake , que es responsable de la interacción y la autenticación de identidad de la clave central; la segunda capa es el protocolo Record , que es responsable de la seguridad de los datos, la integridad y la prueba creíble de los datos después de que se completa el apretón de manos, y el protocolo Handshake se encuentra encima del protocolo Record. Esto también forma una pila de protocolos de este tipo.
Figura 2. Pila de protocolos TLS simplificada
En resumen, los datos en el proceso Handshake también se basan en la capa Record para el cifrado de datos, y la clave cifrada por la capa Record se obtiene mediante la interacción con la capa Handshake. Esto parece ser un punto muerto lógico, pero en realidad se logra a través de una máquina de estado progresiva capa por capa.Además de la engorrosa máquina de estado TLS, este proceso se puede describir básicamente mediante el siguiente diagrama:
Figura 3. Diagrama de flujo de actualización del estado de la clave TLS
En cuanto a los datos transmitidos en texto plano en la etapa inicial de TLS, no viola este proceso, podemos entenderlo como una clave con un valor vacío correspondiente a la etapa inicial de TLS. De la figura anterior, también podemos ver que la implementación de la conmutación de dos fases correspondiente a la línea de puntos debe tener una secuencia estricta. Si el orden está fuera de orden, un extremo no puede completar el análisis de los datos, por lo que el TLS depende mucho del protocolo de transmisión subyacente para garantizar la llegada ordenada de los datos, y esta es una de las principales razones por las que el diseño de TLS es diferente de DTLS y QUIC-TLS. Con esta parte de la reserva de conocimiento, veamos el protocolo de enlace TLS (tomando como ejemplo el escenario de interacción 0-RTT de TLS1.3) , será mucho más claro:
Figura 4. Diagrama de flujo de protocolo de enlace TLS
Se puede ver que el cambio del estado de cifrado correspondiente al texto sin formato "()", "{}", "[]" es básicamente el mismo que el proceso de la figura anterior, y se utilizan datos de marcado típicos como EndOfEarlyData para notificar Se cambia el estado clave del par, y esta comprensión es muy útil para que entendamos el diseño de QUIC-TLS más adelante.
Al final de este capítulo, ofrecemos un breve resumen de TLS:
Figura 5. Resumen de TLS
En términos de uso, TLS proporciona una capa de abstracción de seguridad, lo que permite que la capa de aplicación lea y escriba directamente a través de una simple interfaz de lectura y escritura SSL_read/SSL_write (tome OpenSSL/BoringSSL como ejemplo) , para que pueda usar directamente la capacidad de comunicación segura, y completamente No es necesario prestar atención a los detalles del apretón de manos TLS, las transiciones de estado.
Desde este punto de vista, usar TLS es suficiente para Boring, y en términos de requisitos de seguridad, QUIC-TLS y TLS son lo mismo, y no debería haber una gran diferencia, entonces, ¿qué hace que QUIC-TLS sea tan complicado?
PARTE 3 Diferencias detalladas de QUIC-TLS
En nuestro último artículo, hemos analizado el establecimiento de la conexión QUIC Para garantizar la eficiencia del establecimiento de la conexión QUIC, QUIC combina orden y seguridad. Y sabemos que TLS en sí mismo es un protocolo diseñado en base a TCP, y existe una estricta estratificación entre los dos, y el protocolo TCP garantiza que todos los datos se transmitan con éxito y se transmitan al lado opuesto de manera ordenada, por lo que TLS no necesita considerar la pérdida Embalaje y problemas fuera de servicio. QUIC-TLS necesita considerar los dos juntos. Mirando hacia atrás en el artículo anterior, sabemos que QUIC introdujo el número de paquete y el mecanismo de desplazamiento de cada cuadro para comenzar la transmisión ordenada del primer paquete sin negociación, y los dos Cada uno flag comienza desde 0, y luego se usa TLS para garantizar su seguridad.Los lectores cuidadosos pueden haber descubierto la dependencia circular de la lógica.
Figura 6. Dependencias de protocolo para TLS
Para romper este ciclo interminable, QUIC-TLS debe dividir la interacción a nivel de seguridad en divisiones más detalladas para lograr una transmisión segura y confiable. Por lo tanto, en RFC9001, podemos ver que la pila de protocolos QUIC parece estar Me gusta esto:
Figura 6. Pila de protocolos QUIC-TLS
Este diagrama es algo similar a la pila de protocolos TLS anterior, pero no tanto. Ya sabemos que el efecto capa por capa de la pila de protocolos es que los paquetes generados por el protocolo de la capa superior se incluirán en el protocolo de la siguiente capa en forma de carga útil. El protocolo de protección de paquetes QUIC se utiliza como protocolo para proteger la seguridad de los datos, por lo que sus responsabilidades están relacionadas con TLS. El registro es similar, y el protocolo de transporte QUIC (que garantiza una transmisión confiable y ordenada de QUIC) es similar a TCP. Se puede ver que la parte inferior de la pila de protocolos QUIC es completamente opuesto a la pila de protocolos TLS+TCP, lo que significa que el diseño de QUIC-TLS en la parte inferior debe ser diferente al diseño de TLS. Vamos a desarmarlo en profundidad.
1. Estrategia de encriptación basada en paquetes
Ya sabemos que la función de la capa de registro se basa en el algoritmo de cifrado simétrico para garantizar la seguridad y utiliza el modo de cifrado AEAD para garantizar la credibilidad de los datos.Tome como ejemplo un algoritmo de ejemplo típico AES-128-GCM, AES- 128 significa cifrado simétrico El algoritmo es AES-128, GCM y su correspondiente algoritmo AEAD, el cifrado AES-128-GCM tiene cuatro entradas:
(1) Texto sin formato a encriptar;
(2) Clave encriptada;
(3) Número aleatorio encriptado Nonce;
(4) Datos asociados autenticados.
El descifrado es básicamente el mismo, simplemente reemplace el texto sin formato con el texto cifrado encriptado. Para el valor de Nonce, en TLS, ya que no necesita considerar la transmisión ordenada de datos, Nonce es implementado por el cliente y servidor manteniendo un dispositivo técnico para cada mensaje de Record, es decir, Nonce parte de 0, y cada vez se recibe un par, el mensaje Record del final se incrementa en 1.
Para QUIC-TLS, la transmisión segura de datos a través de algoritmos de cifrado no puede escapar a este conjunto de mecanismos. Sin embargo, para QUIC-TLS, dado que la seguridad y el orden se han integrado, cada vez que recibimos un mensaje, primero debemos descifrarlo para saber si el mensaje está fuera de servicio, por lo que no podemos mantener el contador para lograr auto- servicio ¿Cómo agregar esta función de Nonce?
Vemos que hay un valor monótonamente autocreciente, como el número de paquete (tenga en cuenta que la función del número de paquete no pretende ser un Nonce, y su función específica se dejará a la parte de detección de pérdida de paquetes de QUIC para más detalles). análisis) , que es muy adecuado como Nonce. Pero el número de paquete en sí debe cifrarse, ¿cómo lidiar con esto? La solución no es complicada, es decir, el número de paquete se cifra utilizando un modo de cifrado más débil, es decir, el modo ECB más simple.Tomando como ejemplo AES-128-ECB, este modo solo requiere dos entradas para el cifrado/descifrado:
(1) texto sin formato a cifrar/texto cifrado a descifrar; (2) clave cifrada.
Mirando hacia atrás en el diagrama anterior sobre la transición de estado de TLS, siempre que podamos actualizar continuamente la clave de acuerdo con esta transición de estado, podemos seguir el siguiente proceso para desbloquear el número de paquete y descifrarlo aún más para obtener el protocolo de enlace/aplicación capa información. (Tenga en cuenta que los pasos 3 y 4 no están necesariamente en orden estricto, porque la detección de pérdida de paquetes de QUIC no solo depende del número de paquete, sino también de algunos marcos de control especiales. Para esta parte, la dejaremos para QUIC más adelante. Compártala en artículos relacionados sobre la detección de pérdida de paquetes).
Figura 7. Procesamiento de paquetes para QUIC-TLS
Conociendo este paso, también entendemos por qué QUIC elige usar el paquete QUIC como la unidad básica a nivel de seguridad. Por supuesto, hay varios estados durante un proceso de reconocimiento de QUIC-TLS, es decir, hay varias claves con diferentes encriptaciones. Para que el proceso de interacción de QUIC sea más claro, QUIC también define 6 tipos diferentes de paquetes, que se utilizan para corresponden a 6 tipos State, es decir, 6 claves encriptadas.
Figura 8. Niveles de cifrado de paquetes para QUIC-TLS
La parte Inicial corresponde a la parte de transmisión de texto plano en el proceso TLS, aunque esta parte de los datos está encriptada de nombre, la clave encriptada es un valor escrito en el RFC y conocido por todos, es equivalente a la transmisión de texto claro. No se puede decir que este enfoque sea superfluo, porque aumenta el costo del ataque del atacante hasta cierto punto, pero no garantiza la seguridad de los datos de ClientHello. Con este fin, QUIC-V2 también se está preparando para introducir tecnologías de seguridad como Encrypted-ClientHello para proteger esta parte de los datos, que compartiremos más adelante.
Este modo de cifrado de paquetes, que distingue el tipo pkt, permite que los datos tengan una identificación de transición de estado más clara. Miremos hacia atrás en el diagrama de transición de estado de TLS, y podemos encontrar que cada vez que el par de notificación cambia de key1 a key2, primero debe enviar un mensaje de notificación encriptado con key1 (es decir, ChangeCipherSpec en TLS) y luego ir a Enviar datos cifrados key2, para garantizar teóricamente que el par pueda procesar con éxito el mensaje de notificación y completar el cambio de estado clave. En QUIC-TLS, el tipo de paquete del paquete se convierte en un indicador tan explícito para notificar la transferencia de estado. Por ejemplo, si el par comienza a responder al paquete Handshake, significa que el estado se transferirá al estado Handshake, lo que también hace que QUIC-TLS ya no requiera mecanismos de notificación explícitos como ChangeCipherSpec y EndofEarlyData, y esto es muy útil para el procesamiento desordenado del proceso de reconocimiento. Con este conocimiento de reserva, echemos un vistazo más de cerca a los detalles del apretón de manos QUIC-TLS, y será más fácil comprender su esencia.
2. Falta de capas estrictas, lo que resulta en restricciones de uso de 0-RTT más estrictas
El prototipo de la función 0-RTT vino de QUIC-crypto y se estandarizó formalmente en TLS1.3 También se ha convertido en un punto muy atractivo para los usuarios de TLS1.3, pero las condiciones de uso de esta función son muy estrictas.
En primer lugar, 0-RTT se basa en el éxito de la multiplexación de sesiones TLS, lo que significa que debe haber un mecanismo de confirmación interactivo para su proceso de uso; de lo contrario, el cliente enviará datos 0-RTT en la etapa inicial, pero no se puede confirmar. por el servidor. , entonces esto es una pérdida de recursos;
En segundo lugar, los datos 0-RTT en sí implican la conversión del estado clave, por lo que es necesario diseñar un mecanismo de conversión de estado correspondiente (y el mencionado EndOfEarlyData) ;
Finalmente, los datos 0-RTT en sí son inseguros, porque no pueden evitar los ataques de reproducción y solo pueden confiar en el protocolo de la capa de aplicación para garantizar la idempotencia.
Para la primera pregunta, no hay mucha diferencia entre QUIC-TLS y TLS1.3. Ambos indican si se reciben datos 0-RTT a través de la extensión en la respuesta del servidor. También hemos analizado la segunda pregunta antes. QUIC-TLS se basa en el nivel de cifrado explícito del paquete y no requiere el mecanismo de EndOfEarlyData para notificar al estado clave que se requiere una transición. Pero cuando se trata de la pregunta 3, la situación a considerar será mucho más complicada. Empecemos por el nivel QUIC. Sabemos que QUIC transporta datos de la capa de aplicación a través de tramas tipo STREAM, pero además de transportar datos, QUIC también proporciona dichos datos. como RESET_STREAM, STOP_SENDING Este tipo de cuadro de control se utiliza para controlar la transmisión de datos de la capa de aplicación, y estos no son seguros para la reproducción.
Desde la perspectiva de QUIC, solo puede usar esta capacidad a menos que sepa cómo su protocolo de capa de aplicación opera el flujo de QUIC y tiene una capacidad clara para garantizar la seguridad de reproducción de estos comportamientos. De lo contrario, simplemente déjelo en el estante. Esto también se sugiere claramente en RFC9001.
Y veámoslo desde la perspectiva de HTTP/3.Como mencionamos en el artículo anterior, HTTP/3 no es QUIC+HTTP/2, pero la abstracción del flujo intermedio de HTTP/2 se transfiere a QUIC, y luego controlar estos flujos en HTTP/3. Desde este punto de vista, HTTP/3 cumple de forma nativa los requisitos para el uso de capacidades 0-RTT en QUIC-TLS, pero todavía tenemos muchos problemas que considerar, porque QUIC en sí mismo es un enlace y la transmisión en el enlace tiene muchas posibilidades. Protocolo para parámetros de configuración. Cuando el cliente comienza a transmitir datos de la capa de aplicación, a menudo significa que se han negociado las condiciones de transmisión subyacentes (y debido a la relación vinculante entre HTTP/3 y QUIC, estos parámetros de transmisión también contienen alguna semántica de HTTP/3) , cuando el El cliente transmite datos 0-RTT, no podemos obtener estos parámetros a través de la negociación, pero solo podemos continuar transmitiendo a través de los parámetros de enlace anteriores, por lo tanto, para el escenario QUIC en clúster, garantice la consistencia de la configuración de la máquina en el clúster y la compatibilidad de los cambios. Sexualidad también es un problema importante al que los usuarios de QUIC deben prestar atención.
3. Apretón de manos QUIC-TLS, mayor complejidad traída por fuera de servicio
Primero veamos el diagrama de interacción para QUIC-TLS en RFC9001:
Figura 9. Interacción de protocolo de enlace QUIC-TLS
Solo a partir de este diagrama de protocolo de apretón de manos, si primero simplemente:
(1) Trate el mensaje Init como ClientHello/ServerHello;
(2) El mensaje 0-RTT corresponde a los datos 0-RTT de TLS;
(3) Los datos de HandShake corresponden a ServerFinish/ClientFinish.
Entonces, este proceso de apretón de manos no parece ser diferente de TLS, de hecho, es cierto solo desde la perspectiva del principio del apretón de manos. Sin embargo, cuando introducimos consideraciones fuera de orden, la complejidad del problema será mucho mayor.Como hemos analizado anteriormente, TLS es una capa que se basa en la transmisión ordenada de TCP para garantizar el estado (o el cifrado actual y claves de descifrado) Las capas son progresivas, y debido a que los datos están estrictamente ordenados, TLS solo necesita mantener la clave actual. Cuando se trata de QUIC-TLS, el problema ya no es tan simple, podemos dividirlo en dos casos típicos para discutir:
1. La siguiente etapa del paquete llega antes de lo previsto
Aunque este problema tiene puntos en común en el proceso de protocolo de enlace QUIC-TLS, debe verse en etapas. Cada etapa también tiene sus propias características del problema. En la actualidad, existen varias posibilidades para desencadenar este problema:
-
El mensaje 0-RTT del cliente llega antes que el mensaje Init
-
El mensaje de protocolo de enlace del servidor llega antes que el mensaje de inicialización
-
El mensaje 1-RTT del servidor llega antes que el mensaje de protocolo de enlace del servidor
-
El mensaje 1-RTT del cliente Llega el mensaje Handshake del cliente
Para el primer caso, la solución es realmente muy simple, porque ClientHello en sí no es muy grande, y solo enviaremos un mensaje 0-RTT en el primer paquete (porque no sabemos si el servidor recibirá un mensaje 0-RTT). o no, pruébelo primero) , podemos resolver el problema del desorden en la raíz agregando paquetes QUIC en un paquete UDP y enviándolos (esto está permitido y recomendado por el estándar) .
Sin embargo, el problema de seguimiento es más complicado.En el caso 2, dado que el certificado del servidor puede ser relativamente grande, el paquete Handshake del servidor también será grande y el Init del servidor de agregación por sí solo no puede cumplir con los requisitos. Imagínese, si el cliente elige la estrategia de todo el caché para la situación fuera de servicio, el atacante en el medio puede consumir directamente el caché del cliente enviando continuamente paquetes HandShake.
Y la ingeniosidad de QUIC también está aquí, el acoplamiento de la capa de protocolo puede hacer que otras capas de mecanismos de seguridad también estén disponibles al nivel actual ¿Recuerdas la prevención de ataques de amplificación mencionada en el artículo anterior? Antes de que se complete el protocolo de enlace del cliente, el servidor no puede enviar más de 3 veces los datos hasta que reciba una respuesta del cliente. El cliente puede usar esto como una señal para lidiar con este escenario. Por supuesto, a nivel de implementación, la mayoría de los implementadores seguirán optando por descartar directamente dichos paquetes desordenados, porque mantener dicha cola de caché es en sí mismo un asunto complicado. En este sentido, el RFC también tiene sugerencias correspondientes.El servidor implementa un número limitado de retransmisiones de los datos durante el proceso de negociación antes del final del PTO para acelerar la finalización de la negociación.
Casos 3 y 4 En principio, los problemas que enfrenta el caso 2 no parecen ser muy diferentes, pero los detalles involucrados aún requieren una discusión caso por caso:
En primer lugar, en escenarios de aplicación reales, la situación 3 a menudo no existe, y por qué no existe depende del problema de la situación 4. Solo desde el diagrama de interacción TLS, los datos 1-RTT del cliente llegan antes que el mensaje de protocolo de enlace del cliente, y el servidor realmente tiene una clave 1-RTT en este momento, que puede completar el descifrado de los datos.
Pero considere estos dos casos:
(1) En el escenario de autenticación bidireccional , el protocolo de enlace del cliente lleva los datos de identidad del cliente. El servidor no debe responder a los datos de la capa de usuario antes de que se complete la autenticación, y no debe enviar 1-RTT antes del protocolo de enlace. se ha completado Los datos;
(2) En el escenario 0-RTT , en primer lugar, sabemos que la respuesta correspondiente a los datos 0-RTT es transportada por el mensaje 1-RTT, pero los datos 0-RTT solo pueden confiar en la idempotencia del capa de aplicación debido a problemas de seguridad para lograr la protección contra ataques de repetición. Antes de que el protocolo de enlace no tenga éxito, el servidor no puede confirmar si se han recibido todos los datos 0-RTT, y la capa de aplicación no puede confirmar si los datos son un ataque de repetición sin la cantidad total de datos, por lo que el servidor no puede responder directamente antes de que se complete el protocolo de enlace. Mensaje 0-RTT.
En general, para la consideración del nivel de aplicación, el Caso 4 tiene restricciones más explícitas.RFC9001 estipula directamente que el servidor no debe procesar paquetes 1-RTT antes de que se complete el protocolo de enlace, sino cómo realizar el caché en el nivel UDP en sí mismo. se deja que el implementador lo considere de acuerdo con sus propias condiciones de red.
2. Recibir el paquete de la etapa de cifrado anterior
Justo ahora discutimos cómo manejar los datos del nuevo estado, así que ahora veamos cómo mantener el estado anterior. A partir de la experiencia de TLS, parece intuitivamente que no necesitamos mantener los datos de estado previamente encriptados, y QUIC-TLS y TLS son similares, si un extremo de la comunicación ingresa con éxito a la siguiente fase de protocolo de enlace, también significa que tiene Se reciben todos los mensajes de protocolo de enlace necesarios, por lo que si retransmite los datos de la etapa anterior, ¿los datos son una retransmisión o un ataque, y parece que no hay necesidad de lidiar con eso?
Es cierto que mantener las claves de la etapa anterior es un desperdicio si solo observa el apretón de manos, pero no necesariamente cuando tiene en cuenta la función 0-RTT. Para el cliente, en circunstancias normales, los datos 0-RTT deben enviarse antes que el mensaje de protocolo de enlace del cliente, pero debido a la falta de control del equipo de red intermedio, los datos 0-RTT pueden llegar más tarde que los datos 1-RTT. El servidor puede mantener el estado de cifrado de 0-RTT, por lo que se puede evitar la retransmisión de estos paquetes desordenados. Como hemos discutido antes, 0-RTT en sí mismo no es un mecanismo muy seguro.En QUIC-TLS, el cliente debe eliminar la clave 1-RTT inmediatamente después de que se genera, por lo que no es necesario que el servidor mantenga 0-RTT. durante mucho tiempo El estado de cifrado correspondiente, y para la selección de un tiempo de mantenimiento específico, RFC9001 propone un esquema similar a TCP Time_wait, es decir, el servidor solo necesita mantener la clave 0-RTT como 3 PTO para garantizar que el out Los datos de orden morirán naturalmente en la red.
Además del procesamiento de clave 0-RTT, también hay un mecanismo de actualización de clave en QUIC-TLS, que se utiliza para actualizar la clave de estado actual después de que se completa el protocolo de enlace. claves de estado Sin embargo, su principio es el mismo que el de 0-RTT, por lo que no se repetirá aquí.
PARTE 4 Vuelva a examinar la pila de protocolos QUIC-TLS
Hasta ahora, hemos entendido cómo QUIC-TLS utiliza varios mecanismos detallados para garantizar que su estado pueda evolucionar con éxito capa por capa. Miremos hacia atrás en la pila de protocolos QUIC-TLS en la Figura 6 a continuación. Puede ver que QUIC Packet The Protection parte puede obtener claramente datos de texto sin formato manteniendo la clave de la etapa actual y el mecanismo de mensaje QUIC del nivel de cifrado explícito, mientras que la capa de transporte QUIC proporciona un mecanismo de transmisión relativamente independiente y confiable.
Desde este punto de vista, la parte TLS Handshake de la capa superior se puede desmontar de manera muy fina y funcionalmente independiente. Debido al pensamiento perezoso en ingeniería y la consideración de seguridad y estabilidad, las diversas capacidades de la precipitación TLS existente pueden ser la reutilización debe hacerse tanto como sea posible. Entonces podemos ver que QUIC-TLS define cómo diseñar la API TLS para que pueda interactuar con el QUIC subyacente.
Figura 10. Flujo de interacción entre QUIC-TLS y TLS existente
En este punto, este artículo casi ha completado todo el análisis de la fase de protocolo de enlace QUIC-TLS. Se puede ver que el diseño de QUIC-TLS está lleno de una gran cantidad de consideraciones de acoplamiento entre capas. Cualquier punto de función no es simplemente para satisfacer las demandas. Es necesario considerar tanto el protocolo de aplicación superior como la pila de protocolos. adaptación. Y ese diseño está lleno de varios puntos de la pila de protocolos QUIC. Creo que esta es una de las razones por las que QUIC se ha convertido en un estándar después de tantos años.
De hecho, el artículo es un poco largo para escribir aquí, gracias lectores por poder verlo aquí. Este artículo no menciona muchos procesos detallados involucrados en QUIC-TLS, como el algoritmo de protección de la cabeza y el cifrado del token de reintento.
Desde mi punto de vista personal, estas son funciones relativamente independientes y fáciles de entender. Los lectores deberían poder entender RFC9001 por sí mismos y no se requiere ningún análisis especial.
Por supuesto, si los lectores esperan tener un resumen de este tipo de tecnología, pueden dejar un mensaje al final del artículo , y más adelante se publicará un artículo resumen sobre estas tecnologías.
PARTE 5 Perspectivas para QUIC-TLS
El artículo anterior habló sobre la diferencia entre QUIC-TLS y TLS. En cambio, mirando hacia el futuro, QUIC-TLS es sorprendentemente consistente con la evolución de TLS. Por supuesto, esta también es una conclusión lógica. Porque ya sea QUIC-TLS o TLS, después de todo, es para brindar seguridad a los usuarios, y la próxima generación de tecnologías de seguridad a menudo se enfoca en detalles técnicos como el cifrado y el descifrado. Ojo, es posible que podamos ver la implementación de estas tecnologías en QUIC-V2:
- ClientHello cifrado : esta parte se ha discutido anteriormente. Para hacer que el mensaje Init de QUIC sea más seguro, podemos cifrar el primer paquete a través de tecnología de cifrado de clave pública y sincronización de clave pública fuera de banda. Los lectores interesados pueden ver borradores relacionados.
- Compresión de certificados : la cadena de certificados larga y consistente es una de las razones importantes de la baja tasa de éxito de los apretones de manos en entornos de red débiles. La compresión eficaz de los certificados reducirá en gran medida los datos interactivos y mejorará la tasa de éxito de los apretones de manos. Los lectores interesados pueden ver normas pertinentes.
- Credencial delegada : la seguridad de los entornos de nube pública e híbrida siempre se ha enfrentado a varios desafíos, y las claves privadas, como datos tan importantes, también corren un gran riesgo cuando se implementan en nubes públicas. certificados, puede reducir efectivamente la ventana de ataque, y los lectores interesados pueden ver los estándares relevantes.
- Interacción de secreto de estado : en la situación actual, la seguridad criptográfica se ha elevado a un nivel muy alto y también estamos tratando de estandarizar el algoritmo de secreto de estado en el proceso QUIC-TLS para cumplir con las demandas de cumplimiento y seguridad.
Por supuesto, varias tecnologías emergentes están surgiendo una tras otra, y continuaremos haciendo un seguimiento para garantizar que los usuarios de productos relacionados con Ant también puedan obtener la máxima garantía de seguridad mientras disfrutan de una buena experiencia de red.
PARTE 6 El último elemento a traer
Finalmente, después de leer el intercambio de tecnología, es mejor tener algunos momentos de intercambio de productos y chismes.OpenSSL es de hecho un producto de conciencia de código abierto raro, pero de hecho es un poco confuso en el asunto de QUIC-TLS.
Hace mucho tiempo, los colaboradores de Akamai hicieron presentaciones de relaciones públicas para la función de QUIC-TLS, pero OpenSSL siempre ha utilizado QUIC como la razón por la que no se ha estandarizado y no se consideró la fusión. La comunidad de OpenSSL dijo que no estaba satisfecha. Dado que solo hay compatibilidad con la biblioteca QUIC-TLS, es necesario crear una implementación completa de QUIC por sí mismo (incluidos s_client, s_server y otra compatibilidad con cliente/servidor de prueba para QUIC) , aunque la comunidad está lleno de muchas dudas, pero al final no lograron sacudir su determinación. Por supuesto, esto no significa que la elección de OpenSSL haya sido incorrecta, porque desde la perspectiva de la organización OpenSSL, OpenSSL no está satisfecho con el papel actual de simplemente proporcionando capacidades de biblioteca TLS para QUIC. Avanzando más en el papel de proporcionar una biblioteca QUIC para productos, y la opción actual es su único camino.
Por supuesto, sus ideales son elevados, y la parte difícil es que soy un gran usuario de OpenSSL. De hecho, todavía hay muchos pequeños problemas en el uso de las relaciones públicas de código abierto en la etapa inicial de OpenSSL. La falta de apoyo de la comunidad hará que una gran cantidad de usuarios esperen y vean esta parte de la función Actitud, entonces estos detalles serán más difíciles de exponer, y la motivación de los usuarios para enviar relaciones públicas será mucho más débil. Y debido a la actitud oficial sin soporte de OpenSSL, la mayoría de las bibliotecas QUIC de código abierto también eligen BoringSSL, lo cual es un desastre para algunos productos existentes que se han implementado en base a OpenSSL, y estos productos quieren cambiar a BoringSSL No es nada fácil integrar el biblioteca QUIC correspondiente.
Afortunadamente, siempre hay una solución para cualquier problema. Hemos implementado completamente QUIC-TLS en nuestra biblioteca BabaSSL de código abierto. Además de ayudar a las relaciones públicas originales de la comunidad a mejorar sus funciones correspondientes, también es compatible con algunas API de BoringSSL. , esta parte también pasó la prueba de producción de ant. Los lectores pueden experimentarla. Por supuesto, no solo eso, también estamos implementando o hemos completado la implementación de las tecnologías mencionadas en la perspectiva QUIC-TLS anterior. Los lectores son bienvenidos para venir y probarlo.
aprende más...
BabaSSL Estrella ✨: https://github.com/BabaSSL/BabaSSL
【Link de referencia】
【1】https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14
【2】https://datatracker.ietf.org/doc/html/rfc8879
【3】https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-12
