La compresión HTTP es una capacidad que se puede integrar 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 con el servidor antes de descargar el formato correcto; Los navegadores que no admiten el método de compresión compatible descargarán los datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Brotli ; sin embargo, 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 está transfiriendo, almacenando en caché o referenciado de otro modo está comprimido. La compresión que utiliza Content-Encoding es más compatible que la Transfer-Encoding, y algunos navegadores no anuncian la compatibilidad con la compresión Transfer-Encoding para evitar la activación de errores en los servidores. [3]
Negociación del esquema de compresión
La negociación se realiza en dos pasos, descritos en RFC 2616:
1. El cliente web anuncia qué esquemas de compresión admite al incluir 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 / host HTTP / 1.1 de área cifrada : www.example.com Aceptar codificación : gzip, desinflar
2. 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 Codificación de contenido o Codificación de transferencia 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, 08 de enero de 2003 23:11:55 GMT Rangos de aceptación : bytes Longitud de contenido : 438 Conexión : cerrar Tipo de contenido : texto / html; juego de caracteres = UTF-8Codificación de contenido : gzip
El 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.
Tokens de codificación de contenido
IANA mantiene la lista oficial de tokens disponibles para servidores y clientes, [4] e incluye:
- br - Brotli , un algoritmo de compresión diseñado específicamente para la codificación de contenido HTTP, definido en RFC 7932 e implementado en todos los principales navegadores modernos.
- compress : método de programa "compress" de UNIX (histórico; en desuso en la mayoría de las aplicaciones y reemplazado por gzip o deflate)
- deflate: compresión basada en el algoritmo deflate (descrito en RFC 1951), una combinación del algoritmo LZ77 y la codificación Huffman, envuelto dentro del formato de datos zlib (RFC 1950);
- exi - Intercambio XML eficiente del W3C
- gzip : formato zip GNU (descrito en RFC 1952). Utiliza el algoritmo de desinflado para la compresión, pero el formato de datos y el algoritmo de suma de comprobación difieren de la codificación de contenido "desinflado". Este método es el más ampliamente apoyado a marzo de 2011. [5]
- identidad : no se utiliza ninguna transformación. Este es el valor predeterminado para la codificación de contenido.
- pack200-gzip - Formato de transferencia de red para archivos Java [6]
- zstd: compresión Zstandard , definida en RFC 8478
Además de estos, los servidores o los clientes utilizan una serie de tokens no oficiales o no estandarizados en la naturaleza:
- bzip2 : compresión basada en el formato bzip2 gratuito, compatible con lighttpd [7]
- lzma : la compresión basada en (sin formato) LZMA está disponible en Opera 20 y en enlaces mediante una opción de tiempo de compilación [8]
- peerdist [9] - Almacenamiento en caché y recuperación de contenido de pares de Microsoft
- rsync [10] : codificación delta en HTTP , implementada por un par de proxies rproxy .
- xpress: protocolo de compresión de Microsoft utilizado por Windows 8 y versiones posteriores para las actualizaciones de aplicaciones de la Tienda Windows. Compresión basada en LZ77 que utiliza opcionalmente una codificación Huffman. [11]
- xz : compresión de contenido basada en LZMA2, compatible con un parche de Firefox no oficial; [12] y totalmente implementado en mget desde 2013-12-31. [13]
Servidores que admiten la compresión HTTP
- SAP NetWeaver
- Microsoft IIS : integrado o con módulo de terceros
- Servidor HTTP Apache , a través de mod_deflate (a pesar de su nombre, solo admite gzip [14] ) y mod_brotli
- Servidor HTTP Hiawatha : sirve archivos precomprimidos [15]
- Servidor HTTP Cherokee , sobre la marcha gzip y desinflar compresiones
- Servidor web Oracle iPlanet
- Servidor web Zeus
- lighttpd , a través de mod_compress y el mod_deflate más nuevo (1.4.42+)
- nginx - incorporado
- Aplicaciones basadas en Tornado , si "compress_response" se establece en True en la configuración de la aplicación (para versiones anteriores a 4.0, establezca "gzip" en True)
- Jetty Server : servicio de contenido estático predeterminado integrado y disponible a través de configuraciones de filtro de servlet
- GeoServer
- Apache Tomcat
- IBM Websphere
- AOLserver
- Ruby Rack , a través de Rack :: Deflater middleware
- HAProxy
- Barniz - incorporado. Funciona también con ESI
- Armeria - Entrega de archivos precomprimidos [16]
La compresión en HTTP también se puede lograr utilizando la funcionalidad de lenguajes de programación del lado del servidor como PHP o lenguajes de programación como Java .
Problemas que impiden el uso de la compresión HTTP
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 [17] al día debido al aumento del 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 descomprimirse, cuando se utilizan proxies (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 cae a HTTP 1.0 (sin características como compresión o canalización) cuando está detrás de un proxy, una configuración común en entornos corporativos, era el navegador convencional más propenso a fallar a HTTP sin comprimir. [17]
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), los productos cliente y servidor de Microsoft históricamente lo implementó como un flujo desinflado "crudo", [18] haciendo que su implementación no fuera confiable. [19] [20] Por esta razón, algunos programas, incluido el servidor HTTP Apache, solo implementan codificación gzip .
Implicaciones de seguridad
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 su contenido dado al observar 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 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 las vulnerabilidades 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 aún 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, denominado 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 extraerán), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso. [21] Todas las versiones de TLS y SSL corren el riesgo de INCUMPLIMIENTO, independientemente del algoritmo de cifrado o cifrado utilizado. [22] A diferencia de 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 aprovecha 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 usuarios. [21]
A partir de 2016, el ataque TIME y el ataque HEIST ahora son de conocimiento público. [23] [24] [25] [26]
Referencias
- ^ "Uso de la compresión HTTP (IIS 6.0)" . Microsoft Corporation . Consultado el 9 de febrero de 2010 .
- ^ RFC 2616, Sección 3.5: "La Autoridad de Números Asignados de Internet (IANA) actúa como un registro para los tokens de valor de codificación de contenido".
- ^ 'RFC2616 "Transfer-Encoding: gzip, chunked" no se maneja correctamente' , Chromium Issue 94730
- ^ "Parámetros del protocolo de transferencia de hipertexto - Registro de codificación de contenido HTTP" . IANA . Consultado el 18 de abril de 2014 .
- ^ "Pruebas de compresión: resultados" . Verve Studios, Co. Archivado desde el original el 21 de marzo de 2012 . Consultado el 19 de julio de 2012 .
- ^ "JSR 200: formato de transferencia de red para archivos Java" . El programa Java Community Process.
- ^ "ModCompress - Lighttpd" . laboratorios ligeros . Consultado el 18 de abril de 2014 .
- ^ elinks descompresión LZMA
- ^ "[MS-PCCRTP]: almacenamiento en caché y recuperación de contenido de pares: extensiones del protocolo de transferencia de hipertexto (HTTP)" . Microsoft . Consultado el 19 de abril de 2014 .
- ^ "rproxy: Definición de protocolo para codificación HTTP rsync" . rproxy.samba.org .
- ^ "[MS-XCA]: Algoritmo de compresión Xpress" . Consultado el 29 de agosto de 2015 .
- ^ "Compresión LZMA2 - MozillaWiki" . Consultado el 18 de abril de 2014 .
- ^ "Página del proyecto mget GitHub" . Consultado el 6 de enero de 2017 .
- ^ "mod_deflate - Servidor Apache HTTP Versión 2.4 - Codificaciones admitidas" .
- ^ "Parte adicional del manual del servidor web Hiawatha" .
- ^ "El servicio de archivos estáticos forma parte de la documentación de Armeria" .
- ^ a b "Usa la compresión para hacer que la web sea más rápida" . Desarrolladores de Google . Consultado el 22 de mayo de 2013 .
- ^ "deflate - ¿Por qué los principales sitios web utilizan gzip?" . Desbordamiento de pila . Consultado el 18 de abril de 2014 .
- ^ "Pruebas de compresión: Acerca de" . Verve Studios. Archivado desde el original el 2 de enero de 2015 . Consultado el 18 de abril de 2014 .
- ^ "Pierde la espera: Compresión HTTP" . Rendimiento web de Zoompf . Consultado el 18 de abril de 2014 .
- ^ a b Goodin, Dan (1 de agosto de 2013). "Desaparecido en 30 segundos: nuevo ataque extrae secretos de páginas protegidas por HTTPS" . Ars Technica . Condé Nast . Consultado el 2 de agosto de 2013 .
- ^ Leyden, John (2 de agosto de 2013). "Ingrese al INCUMPLIMIENTO: Nuevo ataque desarrollado para leer datos web encriptados" . El registro . Consultado el 2 de agosto de 2013 .
- ^ Sullivan, Nick (11 de agosto de 2016). "DELITO, TIEMPO, INCUMPLIMIENTO y ATRACO: Una breve historia de los ataques de oráculo de compresión en HTTPS" . Consultado el 16 de agosto de 2016 .
- ^ Goodin, Dan (3 de agosto de 2016). "Explotación HEIST: un nuevo ataque roba SSN, direcciones de correo electrónico y más de las páginas HTTPS" . Consultado el 16 de agosto de 2016 .
- ^ Be'ery, Tal. "¿Un crimen perfecto? EL TIEMPO lo dirá" (PDF) .
- ^ Vanhoef, Mathy. "HEIST: La información encriptada HTTP se puede robar a través de TCP-windows" (PDF) .
enlaces externos
- RFC 2616: Protocolo de transferencia de hipertexto - HTTP / 1.1
- Valores de codificación de contenido HTTP por autoridad de números asignados de Internet
- Compresión con lighttpd
- Coding Horror: Compresión HTTP en IIS 6.0
- 15 segundos: compresión del sitio web en Wayback Machine (archivado el 16 de julio de 2011)
- Compresión HTTP : página de recursos del fundador de VIGOS AG, Constantin Rack
- Uso de la compresión HTTP por Martin Brown de Server Watch
- Usando la compresión HTTP en PHP
- Compresión HTTP dinámica y estática con Apache httpd