Compresión de Brotli para HTTPS

Navega tus respuestas
8

Parece que Chrome, Firefox y pronto Edge admiten el nuevo algoritmo de compresión Brotli solo a través de HTTPS.

No puedo encontrar nada sobre si este nuevo algoritmo de compresión es susceptible al ataque BREACH. Lo único relevante que encontré fue al final de sección 12 de RFC 7932 :

  

Un posible ataque contra un sistema que envía datos comprimidos a través de un      Canal encriptado es el siguiente. Un atacante que puede repetidamente.      mezclar datos arbitrarios (suministrados por el atacante) con datos secretos (contraseñas,      cookies) y observar la longitud del texto cifrado puede potencialmente      Reconstruir los datos secretos. Para protegerse contra este tipo de ataque,      las aplicaciones no deben mezclar datos sensibles con datos no sensibles,      datos potencialmente suministrados por el atacante en el mismo flujo comprimido.

A partir de ese párrafo, parece que Brotli todavía es susceptible de INCUMPLIMIENTO. Si mi comprensión de BREACH (y el ataque de CRIME relacionado) es correcta, la compresión no es segura a través de HTTPS.

En este caso, ¿es seguro utilizar Brotli para el contenido HTTPS? Si no es así, ¿por qué los proveedores de navegadores lo admiten?

    
pregunta rink.attendant.6 04.02.2017 - 05:16
fuente

1 respuesta

7
  

admite el nuevo algoritmo de compresión Brotli solo a través de HTTPS.

En teoría sí. En la práctica, Chrome aceptará actualmente las respuestas comprimidas de brotli con HTTP simple, aunque no anuncie el soporte para brotli en HTTP simple. Firefox solo admite respuestas en HTTPS.

  

Si mi comprensión de BREACH (y el ataque de CRIME relacionado) es correcta, la compresión no es segura a través de HTTPS.

Esta es una generalización incorrecta. El ataque BREACH solo afecta al contenido dinámico que contiene información secreta como tokens CSRF que el atacante le gusta adivinar. Solo funciona si el atacante puede reflejar datos propios en el contenido original, como en el caso de datos reflejados de formularios rellenados. El atacante también debe ser capaz de detectar cambios en el tamaño del contenido comprimido, es decir, mediante el rastreo pasivo de la conexión (ataque BREACH clásico) o mediante la sincronización ( HEIST attack ). Todavía es seguro comprimir el contenido donde no es posible la reflexión y, por supuesto, el contenido que no contiene secretos que el atacante quiera adivinar. Esto significa especialmente que comprimir el contenido estático es seguro.
En cuanto al ataque por CRIMEN, es suficiente deshabilitar la compresión del nivel TLS que ya han hecho los navegadores actuales. CRIME no tiene nada que ver con la compresión de contenido en HTTPS.
Consulte también ¿Se permite el contenido de gzipping a través de TLS ?

    
respondido por el Steffen Ullrich 04.02.2017 - 05:53
fuente

Lea otras preguntas en las etiquetas

¿Es mejor el algoritmo criptográfico en cascada que usar uno solo? Código de malware agregado cuando el sitio se ve externamente