Si has seguido mi serie de posts sobre las ventajas de HTTP/3 (QUIC) en comparación con HTTP/2 (TCP), a estas alturas puede que pienses que estos nuevos protocolos parecen demasiado buenos para ser verdad. Mejoran el rendimiento, aumentan la seguridad y la privacidad, y son la base perfecta para la experimentación y las mejoras de cara al futuro en los próximos años. Sin embargo, los protocolos también han recibido muchas críticas, por varias razones, que trataré en esta última entrada.
Sólo ayuda a los grandes
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, cifrar el tráfico para que no sea visible ni 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 “centro” 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 que finalmente se asigne un único bit en la cabecera del paquete QUIC (llamado “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 graves. El alto grado de cifrado de QUIC también dificulta la creación de cortafuegos, ya que es más difícil distinguir las conexiones reales de las falsas y ya no se pueden observar directamente señales importantes como el cierre de conexiones. 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 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, los debates versan sobre temas bastante fundamentales. Por ejemplo, muchas partes afirman que los nuevos protocolos facilitarán a los delincuentes eludir medidas policiales específicas. O, de forma similar pero algo menos atroz, facilitar que los niños eludan configuraciones como los controles parentales y el filtrado de contenidos. Sin embargo, estos debates no se centran directamente en QUIC o HTTP/3, sino en las iniciativas denominadas “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 Hola del Cliente TLS permite a los usuarios elegir un nombre de sitio web concreto 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 funciones 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 DNS cifrado como Client Hello 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 sobre todo a los puristas del protocolo y no es un argumento convincente para quienes están preocupados por la creciente pérdida de control sobre “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). Aun así, los participantes en el IETF no hacen oídos sordos a estas preocupaciones y ha habido propuestas que permitirían desactivar estas funciones en determinadas redes.
Todo esto es sólo la punta del iceberg
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. Al menos puedo decir que estas afirmaciones son totalmente falsas.
Aunque Google puso en marcha QUIC, se transfirió al IETF, donde muchos otros ingenieros ayudaron a impulsar su diseño hasta lo que es hoy. Claro, 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 realiza en abierto, y todos los documentos y artefactos están a disposición del público. Esto no significa que no hubiera absolutamente ninguna agenda corporativa detrás de algunas decisiones o propuestas, pero está muy lejos de ser colusión.
Aunque no se trata de un complot maligno, no se puede negar que Internet está cada vez más centralizada, con gran parte de sus infraestructuras y servicios críticos controlados y alojados por un pequeño número de grandes empresas. Esta 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 desproporcionada de la distribución del tráfico de Internet.
Creo que esta evolución tiene pros y contras, ya que sin duda hay 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 podamos sufrir de los intermediarios de la red.
HTTP/3 y QUIC están aquí para quedarse
Sopesando las ventajas y los inconvenientes, creo que HTTP/3 y QUIC están aquí para quedarse. Se han diseñado para que estén preparadas para el futuro y puedan evolucionar fácilmente 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.
La historia decidirá si los colaboradores del IETF son luchadores por la libertad o tiranos corporativos. Pero mientras tanto, tenemos una nueva tecnología genial con la que jugar en HTTP/3 y QUIC. Tómatelo como quieras ;).
Robin Marx es Experto en Protocolo y Rendimiento Web en Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.