Los retos futuros de HTTP/3

Si ha seguido mi serie de entradas sobre las ventajas de HTTP/3 (QUIC) en comparación con HTTP/2 (TCP), a estas alturas puede que piense que estos nuevos protocolos parecen demasiado buenos para ser verdad. Mejoran el rendimiento, aumentan la seguridad/privacidad y son la base perfecta para la experimentación y las mejoras de cara al futuro en los próximos años. Aun así, los protocolos también han recibido muchas críticas, por varias razones, que trataré en este último post.

Una crítica común a HTTP/3 y QUIC es que benefician principalmente a los grandes actores y empresas (por ejemplo, Google y Meta), que a menudo controlan uno o incluso dos de los puntos finales (por ejemplo, Google controla servicios populares como YouTube y la búsqueda, así como Chrome, el navegador web más utilizado). Por ello, encriptar el tráfico para que deje de ser visible o utilizable por las partes intermedias no es un problema para estas empresas: de todos modos, sólo trabajan en los puntos finales. Sin embargo, entidades como los proveedores de servicios de Internet (ISP), las empresas de alojamiento o los gobiernos, que operan en el "medio" de la red, se sienten comprensiblemente excluidos por ello.

En algunos casos, las discusiones son relativamente inocentes. Por ejemplo, los proveedores de red se quejan de que es difícil medir el rendimiento de QUIC o solucionar problemas con él en su red. Han presionado largo y tendido en el Grupo de Trabajo de Ingeniería de Internet (IETF) para conseguir finalmente que se asigne un único bit en la cabecera del paquete QUIC (denominado "spinbit") que les permita obtener cierta visibilidad del comportamiento del protocolo. Lamentablemente, para utilizar correctamente el spinbit en las redes, es necesario que los puntos finales lo admitan y lo configuren y, por ejemplo, Google se ha negado (hasta ahora) a implementarlo en Chrome o en sus servidores, alegando (en mi opinión dudosas) razones de privacidad.

En otros casos, los problemas son algo más impactantes. La fuerte encriptación de QUIC también significa que es más difícil de cortafuegos, ya que es más difícil discernir las conexiones reales de las falsas, y las señales importantes como los cierres de conexión ya no se pueden observar directamente. Aunque los cortafuegos pueden (en mi opinión) seguir haciendo una parte importante de su trabajo para QUIC en la práctica (incluso cosas como la inspección profunda de paquetes (DPI) y la interceptación de la seguridad de la capa de transporte (TLS) siguen siendo posibles), esto requiere cambios significativos en sus implementaciones, algo que muchos proveedores de cortafuegos han tardado en hacer. Por ello, muchos proveedores recomiendan deshabilitar QUIC por completo por ahora, ya que los navegadores volverán automáticamente a HTTP/2 sobre TCP en este caso.

En algunos casos, sin embargo, las discusiones versan sobre temas bastante fundamentales. Por ejemplo, muchas partes afirman que los nuevos protocolos facilitarán a los delincuentes eludir determinadas medidas policiales. O, de forma similar aunque algo menos atroz, facilitarán que los niños eludan configuraciones como los controles parentales y el filtrado de contenidos. Sin embargo, estos debates no se centran en su mayoría en QUIC o HTTP/3 directamente, sino en los llamados esfuerzos de "DNS cifrado" y "Client Hello cifrado". Estas dos tecnologías permiten ofuscar aún más los sitios web que los usuarios intentan visitar.

Para aclararlo, el Sistema de Nombres de Dominio (DNS) traduce el nombre de un sitio web a una dirección IP. La indicación del nombre del servidor (SNI) en el TLS Client Hello permite a los usuarios elegir un nombre de sitio web específico si un único servidor aloja muchos de ellos, lo que es habitual. Ambas cosas se hacen a menudo sin cifrar, por lo que los intermediarios de la red pueden leer y manipular o bloquear los sitios web que consideren indeseables (también se utilizan a menudo para proporcionar características como la clasificación cero para servicios populares, una espina en el ojo de los defensores de la neutralidad de la red).

Sin embargo, tanto el DNS cifrado como el Hola del cliente cifrado no son específicos de QUIC o HTTP/3, ya que pueden utilizarse (y se utilizarán) con TCP y HTTP/2. Esto preocupa principalmente a los puristas del protocolo y no es un argumento convincente para aquellos preocupados por la creciente pérdida de control en "sus" redes. Las discusiones aquí son sobre todo de naturaleza ética, con los diseñadores de protocolos presionando generalmente a favor de la máxima libertad individual de los usuarios finales y los gobiernos y otras partes queriendo mantener cierto control (véase también: aplicaciones de mensajería encriptada y posibles puertas traseras para las fuerzas de seguridad). Aún así, los participantes en el IETF no hacen completamente oídos sordos a estas preocupaciones y ha habido propuestas que permitirían desactivar estas funciones en determinadas redes.

Muchos de los que se oponen a estos esfuerzos afirman que sirven a algún intento nefasto de Google y otros (ya que QUIC se desarrolló originalmente en Google) de "tomar el control" de Internet de alguna manera. De estas afirmaciones, al menos, puedo decir que son completamente falsas.

Aunque Google puso en marcha QUIC, fue transferido al IETF, donde muchos otros ingenieros ayudaron a impulsar su diseño hasta lo que es hoy. Claro que muchos de esos ingenieros trabajan en otras grandes empresas como Apple o Meta. Sin embargo, otros proceden de empresas como Mozilla (conocida por su defensa del usuario final) y del mundo académico (como yo).

Además, todo el trabajo del IETF se hace en abierto, y todos los documentos y artefactos están a disposición del público. Esto no significa que no haya absolutamente ninguna agenda corporativa detrás de algunas decisiones o propuestas, pero está muy lejos de ser colusión.

Aún así, aunque no hay ningún complot malvado planeado en estas configuraciones, no se puede negar que Internet está cada vez más centralizada, con gran parte de la infraestructura y los servicios críticos de Internet controlados y alojados por un pequeño número de grandes empresas. Ésta es también la razón por la que HTTP/3 ha experimentado una aceptación relativa tan grande, ya que esta docena de empresas representan una parte desmesurada de la distribución del tráfico de Internet.

Creo que esta evolución tiene pros y contras, ya que sin duda existen ventajas de rendimiento y privacidad para los usuarios finales. Por otro lado, estos beneficios para la privacidad terminan en cuanto los datos llegan a los servidores de estas empresas, y quizá a largo plazo, esos riesgos para la privacidad resulten ser mayores que los que podríamos sufrir con los intermediarios de la red.

Sopesando las ventajas y los inconvenientes, creo que HTTP/3 y QUIC han llegado para quedarse. Han sido diseñados a prueba de futuro y fácilmente evolucionables en los próximos años y décadas. Incluso hoy en día se utilizan como base para protocolos más especializados como WebTransport, MASQUE y Media-over-QUIC, que ofrecen más ventajas para casos de uso específicos.

Que continúe o no el impulso hacia un mayor control del usuario final y/o una mayor centralización de la Web dependerá, creo, en gran medida de las medidas que decidan tomar los gobiernos. Ya hemos visto anteriormente legislación y medidas impactantes para estos temas (por ejemplo, el GDPR y el gran cortafuegos de China), y se están debatiendo más.

Si los colaboradores del IETF resultan ser luchadores por la libertad o tiranos corporativos lo decidirá la historia. Pero mientras tanto, tenemos una nueva tecnología genial con la que jugar en HTTP/3 y QUIC. Tómelo como quiera ;).

Robin Marx es experta en rendimiento y protocolo web de Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.