La compresión HTTP es una capacidad que se puede integrar en servidores y clientes web para mejorar la velocidad de transferencia y la utilización del ancho de banda. [1]
Los datos HTTP se comprimen antes de enviarlos desde el servidor: los navegadores compatibles anunciarán al servidor qué métodos son compatibles antes de descargar el formato correcto; Los navegadores que no admiten métodos de compresión compatibles descargarán datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Brotli ; La IANA mantiene una lista completa de los esquemas disponibles . [2]
Hay dos formas diferentes de realizar la compresión en HTTP. En un nivel inferior, un campo de encabezado Transfer-Encoding puede indicar que la carga útil de un mensaje HTTP está comprimida. En un nivel superior, un campo de encabezado Content-Encoding puede indicar que un recurso que se transfiere, almacena en caché o al que se hace referencia de otro modo está comprimido. La compresión mediante Content-Encoding es más compatible que Transfer-Encoding, y algunos navegadores no anuncian compatibilidad con la compresión Transfer-Encoding para evitar provocar errores en los servidores. [3]
La negociación se realiza en dos pasos, descritos en RFC 2616 y RFC 9110:
1. El cliente web anuncia qué esquemas de compresión admite incluyendo una lista de tokens en la solicitud HTTP . Para Content-Encoding , la lista está en un campo llamado Accept-Encoding ; para Transfer-Encoding , el campo se llama TE .
GET /área cifrada HTTP / 1.1 Host : www.example.com Aceptar codificación : gzip, deflate2. Si el servidor admite uno o más esquemas de compresión, los datos salientes pueden comprimirse mediante uno o más métodos admitidos por ambas partes. Si este es el caso, el servidor agregará un campo Content-Encoding o Transfer-Encoding en la respuesta HTTP con los esquemas utilizados, separados por comas.
HTTP / 1.1 200 OK Fecha : lunes 26 de junio de 2016 22:38:34 GMT Servidor : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Última modificación : miércoles 8 de enero de 2003 23:11:55 GMT Rangos de aceptación : bytes Longitud del contenido : 438 Conexión : cerrar Tipo de contenido : texto/html; charset = Codificación de contenido UTF-8 : gzipEl servidor web no está de ninguna manera obligado a utilizar ningún método de compresión; esto depende de la configuración interna del servidor web y también puede depender de la arquitectura interna del sitio web en cuestión.
La IANA mantiene la lista oficial de tokens disponibles para servidores y clientes [4] e incluye:
Además de estos, tanto los servidores como los clientes utilizan una serie de tokens no oficiales o no estandarizados:
Muchas redes de entrega de contenido también implementan la compresión HTTP para mejorar la entrega rápida de recursos a los usuarios finales.
La compresión en HTTP también se puede lograr utilizando la funcionalidad de lenguajes de secuencias de comandos del lado del servidor como PHP o lenguajes de programación como Java .
Existen varias herramientas en línea para verificar una implementación funcional de la compresión HTTP. Estas herramientas en línea generalmente solicitan múltiples variantes de una URL, cada una con diferentes encabezados de solicitud (con diferente contenido de codificación de aceptación). Se considera que la compresión HTTP se implementa correctamente cuando el servidor devuelve un documento en formato comprimido. [17] Al comparar los tamaños de los documentos devueltos, se puede calcular la relación de compresión efectiva (incluso entre diferentes algoritmos de compresión).
Un artículo de 2009 de los ingenieros de Google Arvind Jain y Jason Glasgow afirma que se desperdician más de 99 años-persona [18] diariamente debido al aumento en el tiempo de carga de la página cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software antivirus interfiere con las conexiones para obligarlas a descomprimirlas, cuando se utilizan servidores proxy (con navegadores web demasiado cautelosos), cuando los servidores están mal configurados y cuando los errores del navegador impiden el uso de la compresión. Internet Explorer 6, que cae a HTTP 1.0 (sin funciones como compresión o canalización) cuando está detrás de un proxy (una configuración común en entornos corporativos) era el navegador principal más propenso a volver a HTTP sin comprimir. [18]
Otro problema encontrado al implementar la compresión HTTP a gran escala se debe a la definición de codificación deflate : mientras que HTTP 1.1 define la codificación deflate como datos comprimidos con deflate (RFC 1951) dentro de una secuencia con formato zlib (RFC 1950), históricamente los productos de servidor y cliente de Microsoft lo implementó como una corriente desinflada "en bruto", [19] haciendo que su implementación no fuera confiable. [20] [21] Por esta razón, algunos programas, incluido el servidor HTTP Apache, solo implementan codificación gzip .
La compresión permite realizar una forma de ataque de texto sin formato elegido : si un atacante puede inyectar cualquier contenido elegido en la página, puede saber si la página contiene el contenido determinado observando el aumento de tamaño de la secuencia cifrada. Si el aumento es menor de lo esperado para inyecciones aleatorias, significa que el compresor ha encontrado una repetición en el texto, es decir, el contenido inyectado se superpone a la información secreta. Esta es la idea detrás del CRIMEN.
En 2012 se anunció un ataque general contra el uso de la compresión de datos, denominado CRIME . Si bien el ataque CRIME podría funcionar eficazmente contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP, solo se demostraron y mitigaron en gran medida los exploits contra TLS y SPDY en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas.
En 2013 se publicó una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH. Un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraerán), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso. [22] Todas las versiones de TLS y SSL están en riesgo de INCUMPLIMIENTO, independientemente del algoritmo de cifrado o cifrado utilizado. [23] A diferencia de instancias anteriores de CRIME , contra las cuales se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH explota la compresión HTTP que, en realidad, no se puede desactivar, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para usuarios. [22]
A partir de 2016, el ataque TIME y el ataque HEIST ahora son de conocimiento público. [24] [25] [26] [27]