Introducción al protocolo QUIC

BurpBurp
4 min read

Viendo que cada vez más servicios DNS soportan DoQ ( DNS Over Quic) me he planteado realizar una reseña del mismo. La idea con esta entrada, es ofrecer una visión general y sencilla del protocolo QUIC sobre el se sustenta DOQ. Con el objetivo de no mezclar ambos en un mismo artículo.

¿Qué es QUIC?

Es el acrónimo de Quick UDP Internet Connections o Conexiones UDP (User Datagram Protocol) rápidas para Internet. Un protocolo de red ideado por el ingeniero de Google Jim Roskind en 2012 con el objetivo de simplificar y aligerar el rendimiento percibido en aplicaciones web que actualmente utilizan TCP.

Desde 2016 existe un grupo de trabajo oficial del IETF que se encarga en exclusiva de optimizar el protocolo QUIC, formado por alrededor de 50 desarrolladores de Google, Mozilla, Microsoft y otras empresas.

Funcionamiento

Consiste en habilitar UDP en varias conexiones multiplexadas entre dos extremos, añadiendo una capa de seguridad mediante TLS/SSL. Podemos decir que actúa de forma similar a HTTP/2 + TLS/SSL, pero utilizando UDP en lugar del clasico TCP.

Con esto se persigue que sea el mismo protocolo quien regule el control de la conexión. De ésta forma, en la primera conexión que tenga lugar, tanto el emisor como el receptor negociarán (handshake) e intercambiarán los certificados y las claves necesarios para el cifrado de los datagramas enviados. Pero dicha negociacion ya no se aplicará en posteriores comunicaciones.

Como protocolo de cifrado se aplica la actual versión TLS 1.3 con velocidad optimizada (versión estandarizada en marzo de 2017), que obtuvo preferencia a una solución criptográfica propia. En términos de multiplexación, QUIC se orienta al protocolo SPDY elaborado por Google, que sirvió de modelo para HTTP/2: los flujos de datos se envían a través de una única conexión cliente-servidor, por lo que disminuye el tiempo de carga.

Ventajas

La que se nos hará más evidente es su rapidez en establecer conexiones. QUIC la inicia una con un único paquete (o dos paquetes si se trata de la primera vez que se establece la conexión) y transmite en ellos todos los parámetros TLS o HTTPS necesarios. En la mayoría de los casos, un cliente puede enviar datos directamente a un servidor sin que este tenga que enviar una respuesta, mientras que TCP debe obtener y procesar la confirmación del servidor.

TCP recurre a los puertos TCP y a las direcciones IP para identificar las conexiones. Así, no es posible que un cliente se comunique con el servidor a través de varios puertos en una única conexión. QUIC recurre a una identificación de la conexión de 64 bits y a diferentes “streams” para transportar los datos en una única conexión. De esta forma se consigue que las conexiones no están vinculadas a un puerto específico, dirección IP o a un punto final determinado.

Cada segmento de datos de una conexión QUIC obtiene un número de secuencia propio, independientemente de que se trate de un segmento original o de uno reenviado. El marcado continuo de los paquetes es, por lo tanto, una ventaja, ya que permite una estimación más precisa del tiempo de recorrido del paquete (RTT, Round Trip Time).

Gracias a su sistema de corrección de errores basado en XOR, no es necesaria una transmisión nueva de los datos que se hayan podido perder, pueden reconstruirse en cualquier momento con ayuda de paquetes FEC (Forward Error Correction), copias de seguridad de los paquetes originales para un grupo de datos.

Al objeto de aumentar la velocidad, TCP siempre intenta enviar datos lo más rápido posible, si un paquete se pierde, se inicia una nueva transferencia (TCP fast retransmit). Ello implica que disminuye de manera momentánea la ventana de visualización, lo que tiene como consecuencia que los datos se transmitan en impulsos.QUIC contrarresta tales picos de carga con ayuda del llamado packet pacing. Éste, se ocupa de que la tasa de transferencia se limite automáticamente, para evitar sobrecargas en conexiones con un ancho de banda reducido.

Uno de los mayores problemas de TCP hace referencia a que el encabezado de los paquetes enviados está redactado como texto simple y puede leerse sin necesidad de autenticación. Por contra, los paquetes QUIC siempre se autentifican y en general suelen estar cifrados (incluso la carga útil o payload). Asimismo, la autenticación por parte del destinatario hace que las partes del encabezado que no se presentan de forma cifrada estén protegidas de la inyección y la manipulación.

Otra gran de ventaja consiste en no depender del sistema. Mientras que los dispositivos y plataformas deben soportar el protocolo TCP para posibilitar la comunicación, el soporte de QUIC solo es necesario en las capas de aplicación. Por eso, en principio son las empresas de software las que integran el protocolo sin depender de los fabricantes de hardware

Activación en navegadores

En Firefox:

  • about:config en la barra de direcciones (aceptamos los riesgos).
  • Buscar y marcar como «True» network.http.http3.enabled

Navegadores basados en Chromium:

  • chrome://flags
  • Experimental QUIC protocol -> enable

En mi experiencia activando QUIC en navegadores Chromium ( Kiwi y Quetta) y utilizando NextDNS como servicio; tan sólo he tenido algún problema de resolución en páginas de Reddit.

0
Subscribe to my newsletter

Read articles from Burp directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Burp
Burp

Android ¬ Hard&Soft ¬ Redes ¬ Domótica y Opinión