Compresión HTTP

La Compresión HTTP es una capacidad que se puede construir en los servidores web y clientes de Internet para mejorar la velocidad de transferencia y la utilización de 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 soportan el método de compresión compatible descargarán los datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Deflate, sin embargo, una lista completa de los sistemas disponibles es mantenida por la IANA.^[2]​ Además, terceros también desarrollan nuevos métodos y los incluyen en sus productos, por ejemplo, el esquema de Diccionario de Google compartido de compresión a través de HTTP (SDCH) implementado en el navegador Google Chrome y se utiliza en los servidores de Google.

Hay dos formas diferentes en que la compresión se puede hacer 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 cabecera Content-Encoding puede indicar que un recurso que se transfiere, almacena, o referencia está comprimido. La compresión usando Content-Encoding está soportada más ampliamente que Transfer-Encoding, y algunos navegadores no publicitan para la compresión Transfer-Encoding para evitar desencadenar errores en los servidores.^[3]​

Esquema de negociación de Compresión

En la mayoría de los casos, excluyendo SDCH, la negociación se hace en dos etapas, como se describe en RFC 2616:

1. El cliente web anuncia qué esquemas de compresión soporta incluyendo una lista de tokens en el HTTP request. Para Content-Encoding, la lista en un campo llamado Accept-Encoding; para Transfer-Encoding, el campo se llama TE.

GET /encrypted-area HTTP/1.1 Host: www.example.com Accept-Encoding: gzip, deflate 

2. Si el servidor soporta uno o más esquemas de compresión, los datos salientes pueden ir comprimidos de una o más formas soportados 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 usados, separados por comas.

HTTP/1.1 200 OK Date: mon, 17 mar 2022 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip 

El servidor web no está para nada obligado a usar algún método de compresión - esto depende de la configuración del servidor web y también puede depender en la arquitectura interna del sitio web en cuestión.

En el caso de SDCH, se requiere una negociación de diccionario adicional, lo que puede involucrar pasos adicionales, como descargar un diccionario apropiado desde el servidor externo.

Tokens de Content-Encoding

La lista oficial de tokens disponible para servidores y clientes es mantenida por IANA,^[4]​ e incluye:

• compress - método del programa UNIX "compress" (histórico; obsoleto en la mayoría de aplicaciones y sustituido por gzip o deflate)
• deflate - compresión basada en el algoritmo deflate (descrito en RFC 1951), envuelto en el interior del formato de datos zlib (RFC 1950);
• exi - Intercambio Eficiente de XML de W3C
• gzip - formato zip GNU (que se describe en el RFC 1952). Este método es el de más amplio soporte a marzo de 2011.^[5]​
• identity - 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]​

Además de éstos, un número de tokens no oficiales o no normalizados se utilizan libremente tanto por servidores o clientes:

• bzip2 - compresión basada en el formato libre bzip2, soportado por [lighttpd]^[7]​
• LZMA - compresión basada en (cruda) LZMA está disponible en Opera 20, y en elinks a través de una opción en tiempo de compilación^[8]​
• peerdist^[9]​ - caché y Recuperación de contenido entre pares de Microsoft
• SDCH^[10]​^[11]​ - Google compresión de HTTP por diccionario compartido, basado en VCDIFF (RFC 3284); soportado en forma nativa en las últimas versiones de Google Chrome, Chromium y Android, así como en los sitios web de Google.
• xz - compresión basada en LZMA2 contenido, soportada con un parche no oficial de Firefox;^[12]​ y aplicado plenamente en mget desde 2013-12-31.^[13]​

Servidores que soportan compresión HTTP

• SAP NetWeaver
• Microsoft IIS: incorporado o utilizando un módulo de terceros.
• Apache HTTP Server, vía mod_deflate (a pesar de su nombre, solo soporta gzip^[14]​)
• Hiawatha HTTP server: entrega archivos pre-comprimidos^[15]​
• Cherokee HTTP server, comprime gzip y deflate en línea
• Oracle iPlanet Web Server
• Zeus Web Server
• lighttpd, via mod_compress y el más nuevo mod_deflate (1.5.x)
• nginx – incorporado
• Las aplicaciones basadas en Tornado, si se fija "compress_response" en Verdadero (True) en la configuración (para versiones previas a 4.0, poner "gzip" en verdadero)
• Jetty Server – incorporado en proveerr contenido estático por omisión y disponible vía configuraciones de filtros de servlets
• GeoServer
• Apache Tomcat
• IBM Websphere
• AOLserver
• Ruby Rack, a través del middleware Rack::Deflater

La compresión en HTTP puede lograrse también usando la funcionalidad de lenguajes de Script del lado del servidor como PHP, o lenguajes de programación como Java.

Problemas que impiden el uso de compresión HTTP

Un artículo de 2009 por Arvind Jain y Jason Glasgow, ingenieros de Google, afirma que más de 99 personas-año se desperdician^[16]​ diariamente debido al mayor tiempo de carga de las páginas cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software anti-virus interfiere con conexiones para obligarlas a ir sin compresión, donde se usan proxies (con navegadores demasiado reticentes), donde los servidores están mal configurados, y donde los errores del navegador impiden usar compresión. Internet Explorer 6, que cae a HTTP 1.0 (sin funciones como la compresión o la canalización) cuando está detrás de un proxy - una configuración común en entornos corporativos - era el navegador dominante más propensos a bajar a HTTP sin comprimir.^[16]​

Otro problema encontrado durante la implementación de la compresión HTTP en gran escala es debido a la definición de codificación de deflate: mientras HTTP 1.1 define la codificación de deflate como datos comprimidos con deflate (RFC 1951) dentro de una corriente de zlib formateado (RFC 1950), los productos de servidor y cliente de Microsoft históricamente lo implementaron como una corriente desinflado "en bruto",^[17]​ lo que hace su implementación no fiable.^[18]​^[19]​ Por esta razón, algunos programas, incluyendo el Apache HTTP Server, sólo implementan la codificación gzip.

Implicaciones de seguridad

Artículo principal: BREACH

En 2012, se anunció un ataque general contra el uso de la compresión de datos, llamado CRIME. Si bien el ataque CRIME podría trabajar eficazmente contra un gran número de protocolos, incluyendo pero no limitado a TLS, y protocolos de capa de aplicación, tales como SPDY o HTTP, sólo exploits contra TLS y SPDY fueron demostrados y en gran medida mitigados en los 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 ser aún más extendida que la compresión combinada de SPDY y TLS.

En 2013, fue publicado una nueva instancia del ataque CRIME contra la compresión HTTP, llamado BREACH. Un ataque BREACH puede extraer tokens de acceso, direcciones de correo electrónico u otra información sensible desde tráfico web encriptado con TLS en tan sólo 30 segundos (dependiendo del número de bytes a ser extraídos), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso.^[20]​ Todas las versiones de TLS y SSL están en riesgo de BREACH independientemente del algoritmo de encriptación o cifrado utilizado.^[21]​ A diferencia de los casos anteriores de CRIME, que se pueden defender con éxito apagando la compresión TLS o compresión de cabecera SPDY, los BREACH explotan la compresión HTTP la cual no puede ser apagada realmente, ya que prácticamente todos los servidores web se basan en ella para mejorar las velocidades de transmisión de datos para los usuarios.^[20]​

Referencias

1. «Using HTTP Compression (IIS 6.0)». Microsoft Corporation. Consultado el 9 de febrero de 2010. 
2. RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) actúa como registro para los valores de los tokens para codificación de contenido."
3. 'RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly', Chromium Issue 94730
4. «Hypertext Transfer Protocol Parameters - HTTP Content Coding Registry». IANA. Consultado el 18 de abril de 2014. 
5. . Verve Studios, Co. Archivado desde el original el 21 de marzo de 2012. Consultado el 19 de julio de 2012. 
6. «JSR 200: Network Transfer Format for Java Archives». The Java Community Process Program. 
7. «ModCompress - Lighttpd». lighty labs. Consultado el 18 de abril de 2014. 
8. elinks LZMA decompression
9. «[MS-PCCRTP]: Peer Content Caching and Retrieval: Hypertext Transfer Protocol (HTTP) Extensions». Microsoft. Consultado el 19 de abril de 2014. 
10. Butler, Jon; Wei-Hsin Lee; McQuade, Bryan; Mixter, Kenneth. «A Proposal for Shared Dictionary Compression Over HTTP». Google. 
11. «SDCH Mailing List». Google Groups. 
12. «LZMA2 Compression - MozillaWiki». Consultado el 18 de abril de 2014. 
13. «Página GitHub del Proyecto mget». Consultado el Mayo de 2014. 
14. . Mark S. Kolich. Archivado desde el original el 20 de agosto de 2011. Consultado el 23 de marzo de 2011. 
15. «Extra part of Hiawatha webserver's manual». 
16. «Use compression to make the web faster». Google Developers. Consultado el 22 de mayo de 2013. 
17. «deflate - Why are major web sites using gzip?». Stack Overflow. Consultado el 18 de abril de 2014. 
18. . Verve Studios. Archivado desde el original el 2 de enero de 2015. Consultado el 18 de abril de 2014. 
19. «Lose the wait: HTTP Compression». Zoompf Web Performance. Consultado el 18 de abril de 2014. 
20. Goodin, Dan (1 de agosto de 2013). «Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages». Ars Technica. Condé Nast. Consultado el 2 de agosto de 2013. 
21. Leyden, John (2 de agosto de 2013). «Step into the BREACH: New attack developed to read encrypted web data». The Register. Consultado el 2 de agosto de 2013. 

•   Datos: Q3495340