Mi Apache es 2.4.46 y usa Openssl versión 1.1.1f
He fijado la directiva SSLCompression Off. Incluso si lo habilito, dice que la compresión SSL no es compatible, lo cual supongo que es bueno.
Pero, cuando uso Firefox para ver los encabezados HTTP de la página web, veo estos encabezados de respuesta:
HTTP/2 200 OK
date: Fri, 25 Dec 2020 12:13:58 GMT
server: Apache
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
vary: Accept-Encoding
content-encoding: gzip
content-length: 3299
content-type: text/html; charset=UTF-8
X-Firefox-Spdy: h2
Lo que dice: content-encoding: gzipme preocupa.
Pero, incluso si uso cURL para buscar la página usando este script en PHP:
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
//enable headers
curl_setopt($ch, CURLOPT_HEADER, 1);
//get only headers
curl_setopt($ch, CURLOPT_NOBODY, 1);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0");
curl_setopt($ch, CURLOPT_ENCODING, "gzip");
Devuelve estos encabezados HTTP:
HTTP/2 200
date: Fri, 25 Dec 2020 12:16:45 GMT
server: Apache
set-cookie: __Secure-CCJRLSESSID=g7m99kljvea2g5uk58f5lfskr1; path=/; secure; HttpOnly; SameSite=Lax
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
content-type: text/html; charset=UTF-8
Lo que me confunde. Incluso borré el caché en Firefox, pero no tuve suerte. No quiero ser vulnerable al ataque CRIMEN. A su vez, podría desactivar gzip por completo. Pero antes de hacer eso, quiero saber por qué sucede esto. ¿Quizás un error con Firefox?
Actualizar:
También sucede en Chrome.
configuración mod_deflate:
SSLCompression Off
<IfModule deflate_module>
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
</IfModule>
Respuesta1
Para responder a su pregunta, es útil saber un poco sobre los antecedentes:
Antecedentes: ¿por qué el uso de la compresión es potencialmente un riesgo para la seguridad?
Existen algunos de los llamados "ataques de canal lateral de compresión" que básicamente utilizan resultados de compresión para intentar adivinar el texto original. Cada uno funciona básicamente al poder agregar la entrada a la compresión y luego observar la salida. Esto se debe a que muchos algoritmos de compresión funcionan reconociendo texto repetido y reemplazándolo con referencias en lugar de repetir el texto completo varias veces. Esto genera mensajes más pequeños, pero abre una oportunidad de ataque.
¿Cómo funcionan estos ataques?
Básicamente, si adivina parte o la totalidad de la parte secreta, agréguela al mensaje junto con la parte secreta desconocida y luego observe el tamaño del resultado cifrado y si se vuelve más pequeño con ciertas conjeturas, entonces debe haber repetido parte de el mensaje se benefició de una mayor compresión.
Con algunas conjeturas es posible descubrir la parte secreta. Hacer esto depende de poder agregar algo al mensaje, pero existen varios métodos para hacerlo. Por ejemplo, si desea conocer un tokenconjunto de cookies para ejemplo.com, envíe un mensaje (¿quizás un mensaje XHR oculto que aparece cuando las personas visitan su sitio totalmente no relacionado?) example.com?token=1y mida el tamaño del mensaje resultante (ya que el navegador agregará automáticamente la cookie al mensaje también). Luego prueba example.com?token=2a ver si es más grande, más pequeño o igual. Repita esto para todos los valores posibles, hasta que haya descubierto el primer carácter de la cookie, donde el mensaje será más pequeño. Digamos en este ejemplo que es token=5. Luego pruebe con el segundo carácter (por ejemplo example.com?token=51, example.com?token=52... etc.). Repite hasta tener la galleta completa.
Puede medir la longitud del mensaje directamente (por ejemplo, observando los mensajes cifrados si puede).Hombre en el mediola red) o el tiempo que se tarda en enviar el mensaje, para poder adivinar su longitud.
Los mensajes HTTP se pueden comprimir de varias maneras
La compresión puede ocurrir en diferentes niveles en un mensaje HTTP: 1) en el nivel SSL/TLS, 2) en el nivel del cuerpo HTTP y 3) en el nivel del encabezado HTTP.
Compresión SSL
La compresión SSL/TLS básicamente ocurre independientemente del hecho de que haya un mensaje HTTP debajo: se realiza en el nivel SSL/TLS. Ataques comoDELITOBásicamente, nos impidió poder usar la compresión SSL/TLS porque introdujo demasiadas formas de adivinar partes ocultas del mensaje, básicamente usando el algoritmo anterior. Para ser honesto, las ganancias de la compresión SSL/TLS no fueron tan buenas de todos modos, especialmente si ya hemos comprimido la respuesta del cuerpo en el nivel HTTP subyacente usando gzip o similar, por lo que comprimirlo nuevamente después de cifrarlo no ahorró mucho. más datos. Así que no hay una razón real para usarlo, y esto dio una razón real.NOpara usarlo. La compresión SSL/TLS siempre debe estar desactivada y utilizar una herramienta comoSSLLabspara confirmar esto. Está desactivado de forma predeterminada en la mayoría de los servidores y lo ha estado durante algún tiempo, por lo que me sorprendería mucho que estuviera activado.
Compresión del cuerpo HTTP
La compresión a nivel de cuerpo HTTP es más interesante. Esto normalmente usa gzip o el algoritmo Brotli más nuevo yESSe recomienda activarlo en la mayoría de los casos, ya que las mejoras en el rendimiento web son significativas. Esto se debe a que los cuerpos HTTP suelen ser grandes (particulares cuerpos de respuesta) y las redes suelen ser relativamente lentas, por lo que se obtienen beneficios reales al enviar tamaños más pequeños a través de la red. Ahora sí, en teoría esto es vulnerable a ataques similares (los llamadosAtaque de incumplimientoy también elTIEMPOvariante), pero solo si los datos secretos están nuevamente en el cuerpo (por lo que se puede ver que cualquier suposición idéntica es menor después de la compresión). Por lo tanto, el riesgo es mucho menor ya que la mayoría de las respuestas no incluyen datos secretos (por ejemplo, ¿cuándo fue la última vez que vio su cookie impresa en la pantalla de una página?), mientras que las cookies en los encabezados a menudo siempre se incluyen y una proporción mayor del mensaje .
Por supuesto, si tiene alguna información secreta impresa en la pantalla (su nombre, número de seguro social, fecha de nacimiento, datos bancarios... etc.), entonces podría ser vulnerable y tal vez debería considerar no comprimir HTTP esas respuestas, pero son bastante atípicas. por lo que deshabilitar la compresión HTTP paracadaLa respuesta rara vez es la respuesta correcta. Incluso cuando se presenta información secreta en la pantalla, existen mejores opciones: por ejemplo, no presentar esos datos en la pantalla en absoluto, o al menos en su totalidad (por ejemplo, tachar todos los dígitos excepto los últimos 4), no permitir que se muestren los datos de respuesta del usuario. en la pantalla al mismo tiempo, rellenar los datos con caracteres aleatorios o agregar un límite de velocidad suelen ser opciones mucho mejores, por ejemplo.
Volver a tu pregunta
Entonces, para responder a su pregunta, la compresión SSL y la compresión de cuerpo HTTP son dos cosas diferentes y la primera debería serapagadoy este ultimoen(excepto en aplicaciones realmente seguras que no quieren correr este riesgo, a pesar de las ganancias, pero incluso entonces, generalmente hay mejores maneras de manejar esto).
Para terminar, información adicional sobre la compresión de encabezados HTTP.
Para finalizar la historia, hablemos de la compresión de encabezados HTTP porque, como se indicó anteriormente, a menudo contienen secretos de cookies que los atacantes encontrarían valiosos.
HTTP/1.1, que hasta hace muy poco era la versión predominante en uso, no permitía esto, por lo que no había mucho de qué hablar aquí. Estos se enviaron en formato completamente sin comprimir (aunque cifrados usando SSL/TLS si se usó HTTPS) y, por lo tanto, no son vulnerables a los riesgos de compresión del canal lateral (suponiendo que no se usó compresión SSL).
Estos también eran típicamente muy pequeños en comparación con los cuerpos HTTP, por lo que nadie se preocupaba realmente por comprimirlos demasiado. Sin embargo, con el aumento en la cantidad de recursos utilizados para crear una página web (más de 100 no es inusual hoy en día), hay mucha redundancia al enviar prácticamente los mismos encabezados HTTP de un lado a otro todo el tiempo (¿has visto el tamaño? del encabezado del Agente de usuario, por ejemplo, que se envía con cada solicitud pero nunca cambia para todas esas solicitudes).
Por lo tanto, los protocolos HTTP/2 más nuevos y HTTP/3 que están a punto de ser lanzados permiten la compresión de encabezados HTTP, pero eligen específicamente un algoritmo de compresión (HPACK para HTTP/2 y el QPACK similar para HTTP/3) que no es vulnerable a estos ataques. Por cierto, esta fue una elección explícita, porque el protocolo SPDY anterior en el que se basaba HTTP/2 usaba gzip y, por lo tanto, era vulnerable. Entonces, cuando se marcó eso, tuvo que cambiarse como parte de la estandarización a HTTP/2.
¿Por qué no utilizar siempre la “compresión segura”?
Entonces, ¿por qué no podemos utilizar técnicas de compresión seguras (como HPACK o QPACK) también para los cuerpos de respuesta HTTP y evitar esto? Pues son técnicas de compresión muy específicas que utilizan diccionarios o valores conocidos y repetidos. Esto funciona bien para encabezados HTTP donde hay pocos valores y que se repiten mucho, pero en realidad no es una opción para las respuestas de cuerpo HTTP de propósito más general que probablemente sean completamente diferentes en cada respuesta.
Espero que eso explique algunas cosas y responda a su pregunta.
Respuesta2
El ataque CRIMEN contraCVE-2012-4929se trata de cifrar los encabezados comprimidos sin ofuscar adecuadamente la longitud de los datos no cifrados, lo que hace posible revelar encabezados de texto sin formato (mediante adivinanzas).
En su situación, los contenidos se comprimen, el tamaño (longitud) de los datos comprimidos se agrega como otro encabezado y luego todo esto se cifra. Esto no es vulnerable al ataque CRIME, ya que nunca se revela la longitud de los datos no cifrados.