Llegamos a ustedes gracias a:



Reportajes y análisis

6 formas en que el HTTP/3 beneficia a la seguridad

Y 7 serias preocupaciones

[21/07/2020] El HTTP3, la tercera versión oficial del protocolo de transferencia de hipertextos (HTTP, por sus siglas en inglés), no utilizará el protocolo de control de transmisiones (TCP, por sus siglas en inglés) como lo hicieron sus predecesores. En su lugar, utiliza el protocolo QUIC (quick UDP Internet connections), desarrollado por Google en el 2012.

QUIC es un protocolo de la capa de transporte basado en una versión multiplexada de las conexiones UDP (user datagram protocol). A diferencia del TCP, el UDP no sigue el protocolo de enlace (handshake) de tres vías de TCP, sino que utiliza un solo UDP, ida y vuelta. Por lo tanto, el protocolo QUIC mejora exponencialmente el rendimiento de red de cualquier componente web, ya que utiliza un UDP para cada conexión entre el agente del usuario y el servidor web. Además, QUIC se basa en el multiplexing para gestionar múltiples interacciones entre el agente de usuario y el servidor, de forma constante, a través de una sola conexión -sin que nadie bloquee a otro, lo que ayuda a mejorar el rendimiento en comparación con sus predecesores.

Con varios beneficios desde la perspectiva del rendimiento y la fiabilidad, HTTP/3 se considera el camino correcto. Desde la perspectiva de la seguridad y la privacidad, existen beneficios y limitaciones, y la mayoría se detalla ampliamente en el campo de la investigación. Este artículo proporciona detalles sobre los beneficios proporcionados por el HTTP/3 y algunas consideraciones de seguridad que deben tenerse en cuenta.

Funciones de seguridad y beneficios

Cifrado de extremo a extremo: El protocolo TCP fue diseñado para garantizar que el cifrado de la carga útil estuviera presente durante la transmisión, pero la información específica del transporte aún no estaba cifrada, lo que planteó muchos problemas de seguridad y privacidad. Las contramedidas diseñadas e implementadas para evitar estos ataques no están en el stack de TCP, sino en los dispositivos de red y las cajas intermedias que manejan el protocolo y la red. Además, los analizadores en los balanceadores de carga, creados para superar estos problemas, y otros dispositivos de red, tienen serios problemas de rendimiento y pueden limitar las futuras expansiones de red que evolucionan rápidamente y dependen de la velocidad y confiabilidad de la red.

Con el protocolo QUIC, solo los campos obligatorios en el segmento de red no están encriptados, mientras que el resto de la información está cifrada de manera predeterminada. Al revisar el segmento de red de TCP y QUIC, encontramos que los campos que incluyen las banderas de los paquetes (Packet NR y ACK NR), ventana y opciones están encriptados en QUIC, pero no en TCP. El cifrado propuesto en QUIC ayuda a evitar ataques de monitoreo generalizados, que prevalecían en los predecesores de HTTP/3, así como la recopilación de información intrusiva de artefactos de protocolo y metadatos, y de datos de aplicaciones.

A continuación, la Figura 1 muestra cómo se ve el protocolo QUIC en la herramienta de análisis de red, Wireshark. Según el segmento de red de QUIC, la capa de protocolo de Internet (IP, por sus siglas en inglés) contiene la información de la dirección IP de origen y de destino. UDP contiene el puerto de origen y el de destino, mientras que el QUIC contiene los indicadores públicos, el número de paquete, la ID de conexión y la carga útil cifrada.

Figura 1: fragmento de Wireshark que muestra los segmentos de red del protocolo QUIC.
HTTP/3

Conectividad segura TLS: Para soportar el cifrado de extremo a extremo durante las conexiones, QUIC depende en gran medida de los acuerdos entre la capa de transporte y la criptográfica. Dado que QUIC interactúa directamente con el TLS 1.3, ha exigido el cifrado utilizado para todas las conexiones de origen, y no hay ninguna opción para deshabilitar TLS. QUIC también asume la responsabilidad de garantizar que se establezcan conexiones seguras, teniendo en cuenta las protecciones de confidencialidad e integridad para todas las conexiones de origen. A diferencia de la implementación HTTP/2 + TLS, QUIC maneja el acuerdo con TLS y los mecanismos de alerta en su contexto de transporte, lo que a su vez ayuda a QUIC a establecer protecciones criptográficas, utilizando las llaves intercambiadas desde el acuerdo.

Si consideramos el protocolo como un todo, existen dos comunicaciones principales entre TLS y QUIC:

1. QUIC proporciona una abstracción confiable del stream para que TLS envíe y reciba mensajes a través de QUIC.

2. TLS actualiza el componente QUIC con lo siguiente:

  • Algoritmos de cifrado secreto y autenticado, y una key derivation function (KDF),
  • Llaves de protección de paquetes,
  • Cambios en el estado del protocolo (tales como los estados del protocolo de enlace, los certificados del servidor).

A diferencia de HTTP/2, que usa los registros "application data del TLS, QUIC usa cuadros STREAM en forma de paquetes QUIC. Los protocolos de enlace TLS ocurren en forma de cuadros CRYPTO, que están compuestos principalmente por los datos de los protocolos de enlace en una secuencia continua. QUIC está diseñado para enviar paquetes en paralelo, a veces agrupando diferentes mensajes en uno y cifrándolos, considerando que esos mensajes tienen el mismo nivel de cifrado. Esta función proporciona excelentes beneficios para el rendimiento de la red, a la vez que garantiza que se apliquen los modos de cifrado adecuados durante la transmisión.

Secreto pleno hacia adelante:Se puede lograr el 'secreto perfecto hacia adelante' (PFS, por sus siglas en inglés) cuando se intercambian llaves privadas temporales entre los agentes-usuario y los servidores. Cada sesión iniciada por el agente-usuario utiliza una nueva llave de sesión única, y no tiene ninguna relación con la llave de sesión anterior. Al usar una llave de sesión separada para cada transacción, cualquier información de sesiones anteriores o futuras no puede verse comprometida, incluso si alguna llave de sesión está comprometida. Desde una perspectiva criptográfica, ningún intercambio de llaves puede proporcionar PFS. Sin embargo, un nuevo término, el 'secreto pleno hacia adelante', brinda una expectativa realista del PFS.

QUIC usa TLS 1.3, que soporta tanto llaves previamente compartidas (PSK, por sus siglas e inglés) como Diffie-Hellman (DH) sobre intercambios de llaves DHE de curvas elípticas (EC, por sus siglas e inglés) o campos finitos. Los intercambios de llaves 0-RTT proporcionan pleno secreto hacia adelante, ya que la especificación criptográfica solo acepta conexiones seguras de reenvío a través de protocolos de enlace 0-RTT. Si bien TLS 1.2 también soporta el secreto hacia adelante, el secreto hacia adelante se pierde técnicamente durante la reanudación de la sesión, cuando el agente-usuario envía una copia del material secreto protegido por una llave simétrica conocida solo por el servidor. El protocolo proporciona secreto pleno hacia adelante incluso a los mensajes iniciales entre el agente-usuario y el servidor. Además, dado que el protocolo QUIC no soporta llaves secretas a largo plazo, QUIC, con la ayuda de TLS 1.3, puede proporcionar una función de secreto pleno hacia adelante para las aplicaciones que utilizan su capa de protocolo.

Protección contra ataques de reinyección:La implementación de QUIC está diseñada para almacenar los valores del cliente de la derivación de la llave, además de nonces. El servidor identifica y descarta cualquier solicitud repetida con el mismo valor de derivación de llave y valores de seguridad (nonces). Se sabe que este diseño es una pesadilla en cuanto a rendimiento, considerando la sobrecarga de tráfico de protocolo entre el agente-usuario y el servidor. Teóricamente, la solución puede parecer aplicable, pero en la práctica, el protocolo puede ser más voluminoso y generar problemas de rendimiento. El diseño actual no es el mejor, pero esto impide que, desde el nivel de protocolo, cualquier servidor acepte la misma llave más de una vez. Además, QUIC no proporciona protección contra reinyección durante los pasos iniciales e inicia la protección justo después de la respuesta inicial del servidor. El diseño de QUIC equivale a permitir que la transacción inicial esté protegida por las aplicaciones y ahorrar en la sobrecarga del protocolo. Teniendo en cuenta que los componentes web pueden usar una llave derivada de la llave de sesión, es posible que surjan ataques de reinyección en esta etapa; sin embargo, se pueden usar medidas de precaución a nivel de aplicación para mitigar esto.

Protección contra suplantación de IP:QUIC soporta la validación de direcciones durante el protocolo de enlace y requiere una prueba firmada de las direcciones, eliminando así cualquier ataque de suplantación de IP. En QUIC, el problema de suplantación de la dirección IP se maneja, principalmente, utilizando el "token de dirección de origen. Este token es un bloque de cifrado autenticado del servidor, que contiene la dirección IP del agente-usuario y la marca de tiempo del servidor. Los agentes-usuario pueden reutilizar el token de dirección de origen generado por los servidores hasta que sus direcciones IP no se hayan movido debido a cambios de conectividad. Dado que los tokens de dirección de origen se usan como tokens de portador, se pueden reutilizar y se pueden omitir las restricciones de dirección IP establecidas por el servidor. Dado que el servidor solo responde a la dirección IP en el token, puede que incluso una cookie robada o el token no logren la suplantación de la IP. Además, teniendo en cuenta que QUIC soporta tokens de direcciones de origen de corta duración, la ventana de tiempo de un ataque exitoso de suplantación de IP será prácticamente imposible.

Prevención de downgrade de SSL: Por diseño, TLS 1.3 protege contra los ataques de downgrade de TLS, ya que el protocolo exige una clave hash de todas las comunicaciones de protocolo de enlace y requiere que el receptor del protocolo de enlace verifique el código de llave enviado. Durante el protocolo de enlace, cualquier intento de manipulación detectado en las capacidades del cliente dará como resultado la finalización del protocolo de enlace con un error. Además, los mensajes CertificateVerify, entre el agente-usuario y el servidor, incluyen una firma de hash PKCS RSA de todos los mensajes anteriores sobre la conexión específica. Esta implementación de suma de verificación en QUIC evitará un ataque exitoso de downgrade de TLS.

Los impactos del HTTP/3 sobre la seguridad

Vulnerabilidades de reanudación de 0-RTT:Una de las funciones más ventajosas del HTTP/3 es la reanudación de 0-RTT, que mejora drásticamente la velocidad de conectividad y reduce la latencia. Sin embargo, este proceso solo funciona cuando se ha establecido una conexión anterior con éxito, y la transacción actual utiliza el secreto compartido previamente, que fue establecido durante la última conexión.

Existen algunos inconvenientes de seguridad debido a la función de reanudación 0-RTT. Uno de los vectores de ataque más comunes es reproducir los ataques que pueden ser causados cuando un adversario reenvía el paquete inicial; en contextos específicos, esto puede obligar al servidor a creer que la solicitud proviene de un cliente previamente conocido. Otro inconveniente de seguridad de la reanudación de 0-RTT es la falla parcial del secreto pleno hacia adelante. Si un adversario compromete los tokens, puede descifrar las comunicaciones 0-RTT enviadas por el agente-usuario.

Ataques de manipulación de ID de conexión:Los ataques de manipulación de ID de conexión requieren que se coloque un atacante entre el agente-usuario y el servidor. Pueden manipular la ID de conexión durante el protocolo de enlace inicial, donde se intercambian los mensajes de saludo del cliente y el servidor. El protocolo de enlace continuará normalmente y el servidor asumirá que la conexión está establecida, pero el agente-usuario no podrá realizar el descifrado porque la ID de conexión es un input del proceso de derivación de la llave de cifrado y el agente-usuario y el servidor calcularán llaves de cifrado diferentes. El agente-usuario finalmente agota el tiempo de espera y envía un mensaje de error al servidor, comunicándole que la conexión ha finalizado. Como el cliente cifra el mensaje de error al servidor con la llave de cifrado original, el servidor no podrá descifrarlo y retendrá el estado de conexión hasta que caduque el tiempo de espera de la conexión inactiva (generalmente en 10 minutos).

Cuando se realiza a mayor escala, el mismo ataque puede crear un ataque de denegación de servicio en el servidor, con múltiples conexiones retenidas hasta que expire el estado de conexión. Otro método de ataque para mantener viva la conexión sería alterar otros parámetros, como los tokens de dirección de origen, evitando así que los clientes establezcan cualquier conexión.

Ataque de amplificación UDP:Para un ataque de amplificación exitoso, el adversario tiene que falsificar la dirección IP de la víctima y enviar una solicitud UDP al servidor. Si el servidor devuelve una respuesta UDP más significativa, el adversario puede utilizar este comportamiento del servidor a mayor escala y crear un escenario de ataque de denegación de servicio en el servidor (DDOS, por sus siglas en inglés).

Específicamente, en QUIC, los ataques de amplificación UDP ocurren cuando un adversario acepta un token de validación de dirección del objetivo y libera la dirección IP que se utilizó inicialmente para generar el token. Un atacante puede enviar una conexión 0-RTT al servidor con la misma dirección IP, que puede haber cambiado, para apuntar a un terminal diferente. Con la ejecución exitosa de esta configuración, el atacante podría instruir al servidor para que envíe tráfico sustancial hacia el servidor víctima. Para evitar este ataque, HTTP/3 tiene funciones de limitación de velocidad y tokens de validación de corta duración que puedan actuar como un control compensatorio para los ataques DDOS, mientras que mitigan parcialmente el contexto de ataque.

Ataque de agotamiento de flujo:Un ataque de agotamiento de flujo ocurre cuando un adversario inicia múltiples flujos de conexión intencionalmente, lo que puede provocar que un terminal se agote. El atacante puede utilizar la secuencia de agotamiento inundando la solicitud repetidamente. Si bien los parámetros de transporte específicos pueden limitar el número de secuencias activas concurrentes, podría haber contextos en los que la configuración de un servidor se haya establecido intencionalmente en una cantidad mayor. Los servidores de las víctimas pueden ser el objetivo de tales ataques debido a las configuraciones de protocolo de servidor para aumentar el rendimiento del protocolo.

Ataque de restablecimiento de conexión:Los ataques de restablecimiento de conexión principalmente envían restablecimientos sin estado a las víctimas, creando así la posibilidad de ataques de denegación de servicio similares a los ataques de inyección de restablecimiento de TCP. El vector de ataque potencial es posible si un adversario puede obtener un token de reinicio generado para una conexión con una ID de conexión específica. Finalmente, el atacante puede usar el token generado para restablecer una conexión activa que tenga la misma ID de conexión, haciendo que el servidor espere la conexión hasta que se agote el tiempo de espera. Si este ataque se realiza a mayor escala, el servidor debe quemar considerablemente sus recursos solo para esperar a que se completen las conexiones.

Ataque de downgrade de la versión de QUIC:La protección de paquetes QUIC proporciona autenticación y cifrado para todos los paquetes en la comunicación, excepto los paquetes de negociación de versiones. Los paquetes de negociación de versiones están diseñados para negociar la versión de QUIC entre el agente-usuario y el servidor. La función puede permitirle a un atacante migrar a una versión anterior y probablemente insegura de QUIC. Este ataque no es aplicable actualmente, ya que solo existe una versión de QUIC, pero es algo para tener en cuenta en el futuro.

Falta de soporte de monitoreo:Aunque varios agentes-usuario, servidores y páginas web acreditados son compatibles con HTTP3/QUIC, muchos dispositivos de red como los servidores proxy inversos/de reenvío, balanceadores de carga, firewalls de aplicaciones web y herramientas de monitoreo de eventos de seguridad no son totalmente compatibles con HTTP/3. A diferencia del TCP, no se necesitan sockets en una conexión QUIC, lo que dificulta la detección de hosts y conexiones maliciosas. Un atacante malintencionado puede retransmitir cargas maliciosas y realizar ataques de extracción de datos a través de QUIC y permanecer sigiloso, ya que la mayoría de las herramientas de detección no detectarían el tráfico de QUIC.

Historia de QUIC

En el 2016, el grupo de trabajo de ingeniería de Internet (IETF) comenzó a estandarizar el QUIC de Google y recientemente anunció que IETF QUIC sería la columna vertebral de la nueva versión HTTP/3. Sin embargo, por razones de rendimiento y seguridad, IETF QUIC se ha desviado significativamente del diseño QUIC original.

El tráfico web tradicional a través de TCP requiere un protocolo de enlace de tres vías; QUIC usa UDP, que acelera el tráfico web debido a una menor demora como resultado de menos viajes de ida y vuelta y menos paquetes enviados. Además de ser más rápido, UDP proporciona varios beneficios, incluida la migración de conexión, latencia mejorada, control de congestión y cifrado incorporado. Según Google, "los protocolos de enlace de QUIC a menudo requieren cero viajes de ida y vuelta antes de enviar la carga útil, en comparación con 1-3 viajes de ida y vuelta para TCP + TLS. La primera conexión requiere un viaje de ida y vuelta, y los siguientes no necesitan ningún viaje de ida y vuelta. Además, debido a que QUIC está destinado a la operación multiplexada, se ocupa mejor de la pérdida de paquetes que TCP y permite protocolos de enlace más rápidos.

La versión de Google de QUIC ahora es gQUIC. HTTP/3 ha evolucionado significativamente desde gQUIC con contribuciones y mejoras del grupo de trabajo IETF. Si bien HTTP/3 es técnicamente el protocolo de aplicación completo, QUIC se refiere al protocolo de transporte subyacente, que no se limita a servir el tráfico web. UDP no tiene conexión y no es muy confiable; QUIC supera estas limitaciones al agregar un stack similar a TCP por medio de UDP para agregar una conexión confiable y reenviar con funciones de control de flujo, mientras resuelve el bloqueo de la cabecera de TCP.

HTTP/3 usa UDP, similar a cómo HTTP/2 usa TCP. Cada conexión tiene varias secuencias paralelas que, simultáneamente, se utilizan para transferir datos a través de una única conexión sin afectar otras secuencias. Por lo tanto, a diferencia de TCP, los paquetes perdidos que transportan datos para una secuencia individual específica solo afectan a esa secuencia en particular. Cada trama de transmisión se puede enviar inmediatamente a esa transmisión a su llegada, por lo que las transmisiones sin pérdida pueden continuar ensamblándose en la aplicación. Esta estrategia de establecimiento de conexión de QUIC se habilita mediante la combinación de protocolo de enlace de cifrado y transporte.

Análisis comparativo con HTTP/2

QUIC fue diseñado para mejorar el rendimiento al mitigar los problemas de pérdida de paquetes y latencia con HTTP/2. Si bien HTTP/2 usa una única conexión TCP para cada origen, esto lleva al problema de bloqueo de cabecera. Por ejemplo, el objeto de una solicitud puede detenerse detrás de otro objeto que ha experimentado una pérdida, hasta que pueda recuperarse. QUIC aborda este problema empujando la capa de flujo de HTTP/2, hacia abajo, a la capa de transporte, evitando así el problema tanto en la aplicación como en las capas de transporte. HTTP/3 también permite la multiplexación, entregando una solicitud independiente de otras solicitudes de conexión, mientras se integra directamente con el TLS. Si bien HTTP/2 y HTTP/3 funcionan de manera similar, a continuación, se presentan algunas de las diferencias significativas en las funciones de HTTP/2 y HTTP/3.

Diferencias HTTP/2 HTTP/3
Transporte TCP QUIC con UDP
Capa de flujos Aplicación Transporte
Cifrado por defecto No
Flujos independientes No
Compresión de encabezado HPACK QPACK
Acuerdos  Más rápido, 0 viajes de ida y vuelta 1-3 viajes de ida y vuelta para TCP + TLS
Mitigación de conexión No
Congestión Control Pérdida Recuperación Realizado por TCP Realizado por QUIC

Desde la perspectiva del stack de red, HTTP/2 utiliza ampliamente TLS 1.2+ en alineación con el estándar HTTP, con TCP subyacente, que actúa como un protocolo de transmisión. Sin embargo, en HTTP/3, TLS 1.3 se usa de forma predeterminada además de QUIC, siendo UDP el protocolo de transmisión. El siguiente diagrama ilustra dónde se encuentra QUIC en el stack de protocolos de red. En comparación, la versión anterior usa TLS 1.2 y utiliza las funciones de recuperación de pérdida de control de congestión de TCP, donde HTTP/2 maneja las capacidades de transmisión múltiple.  

Figura 2: Ubicación de QUIC en el stack de protocolos de red.
HTTP/3

Beneficios de la ID de conexión

Las conexiones TCP se han diseñado para utilizar entidades de red de origen y destino (principalmente direcciones y puertos) con el fin de identificar una conexión específica. Sin embargo, una conexión QUIC utiliza una ID de conexión, que es un identificador de cliente generado de forma aleatoria de 64 bits. Este cambio es muy beneficioso para las tecnologías web actuales, ya que son necesarias para soportar la movilidad del usuario como factor principal. Si un usuario pasa de una red Wi-Fi a una red celular, el protocolo TCP HTTP/2 necesitaría establecer una nueva conexión basada en la dirección actual. Sin embargo, dado que el protocolo HTTP/3 QUIC utiliza una ID de conexión aleatoria, una dirección IP que cambia el cliente en HTTP/3, al pasar de una red celular a una conexión Wi-Fi, continuará usando la ID de conexión existente sin interrupción.

Desde la perspectiva del protocolo, la ID de conexión proporciona beneficios adicionales. Utilizando la ID de conexión, el servidor y los agentes de usuario pueden identificar las conexiones originales frente a las de retransmisión y evitar problemas de ambigüedad de retransmisión prevalentes en TCP.

Conclusión

QUIC ha estado recibiendo plena aceptación y soporte de los navegadores; importantes páginas web como YouTube y Facebook lo han habilitado para cargar las páginas más rápidamente. Al momento de escribir este artículo, solo el 4% de los principales sitios actualmente soportan QUIC. Microsoft ha anunciado que enviará Windows con una biblioteca QUIC de propósito general, MsQuic, en el núcleo para soportar varias funciones de la bandeja de entrada.

QUIC y HTTP/3 están diseñados para cumplir con los objetivos actuales de Internet respecto a rendimiento, confiabilidad y seguridad de la red. Se han dado mejoras significativas en la seguridad con el soporte obligatorio para TLS 1.3, abordando las debilidades con HTTP/2 y versiones anteriores de HTTP. El uso del cifrado de extremo a extremo durante el tránsito en HTTP/3 ayuda a defenderse contra varios problemas de privacidad relacionados a actores de estado y agregadores de datos. Si bien existen algunas debilidades, HTTP/3 continuará evolucionando y es una mejora significativa con respecto a HTTP/2, tanto desde el punto de vista del rendimiento como de la seguridad.

Referencias