La compresión HTTP es una capacidad que se puede incorporar en servidores web 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 ser enviados desde el servidor: los navegadores compatibles anunciarán qué métodos son compatibles al servidor antes de descargar el formato correcto; los navegadores que no admiten el método de compresión compatible 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]
Existen 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 está transfiriendo, almacenando en caché o al que se hace referencia de otro modo está comprimido. La compresión mediante Content-Encoding tiene un mayor soporte que la de Transfer-Encoding, y algunos navegadores no anuncian su compatibilidad con la compresión Transfer-Encoding para evitar generar 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 . En el caso de Content-Encoding , la lista se encuentra en un campo llamado Accept-Encoding ; en el caso de 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 : cerrada Tipo de contenido : text/html; charset=UTF-8 Codificación del contenido : gzipEl servidor web no está obligado de ninguna manera 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 lista oficial de tokens disponibles para servidores y clientes la mantiene la IANA, [4] e incluye:
Además de estos, los servidores o clientes utilizan en la red una serie de tokens no oficiales o no estandarizados:
Muchas redes de distribución 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 script 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 suelen solicitar múltiples variantes de una URL, cada una con diferentes encabezados de solicitud (con contenido de Accept-Encoding variable). Se considera que la compresión HTTP se implementa correctamente cuando el servidor devuelve un documento en un formato comprimido. [17] Al comparar los tamaños de los documentos devueltos, se puede calcular la tasa 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 del tiempo de carga de las páginas cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software antivirus interfiere con las conexiones para obligarlas a descomprimirse, cuando se utilizan servidores proxy (con navegadores web demasiado cautelosos), cuando los servidores están mal configurados y cuando los errores del navegador impiden que se utilice la compresión. Internet Explorer 6, que se reduce 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), fue 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 un flujo con formato zlib (RFC 1950), los productos de servidor y cliente de Microsoft históricamente lo implementaron como un flujo deflate "sin procesar", [19] lo que hace que su implementación no sea confiable. [20] [21] Por esta razón, algunos programas, incluido el servidor HTTP Apache, solo implementan la codificación gzip .
La compresión permite realizar una forma de ataque de texto simple elegido : si un atacante puede inyectar cualquier contenido elegido en la página, puede saber si la página contiene el contenido dado observando el aumento de tamaño del flujo cifrado. 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 de CRIME.
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 de manera efectiva 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, a pesar de que 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 con TLS en tan solo 30 segundos (según la cantidad de bytes que se extraigan), 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 por BREACH independientemente del algoritmo de cifrado o el cifrado utilizado. [23] A diferencia de las instancias anteriores de CRIME , contra las que se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH explota la compresión HTTP que no se puede desactivar de manera realista, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios. [22]
A partir de 2016, el ataque TIME y el ataque HEIST son ahora de conocimiento público. [24] [25] [26] [27]