Tengo estas pocas directivas de compresión a nivel http en nginx:
gzip on;
gzip_http_version 1.1;
gzip_vary on;
Leí que esto debería evitarse debido al ataque de CRIME / BREACH, ¿es correcto?
Tengo estas pocas directivas de compresión a nivel http en nginx:
gzip on;
gzip_http_version 1.1;
gzip_vary on;
Leí que esto debería evitarse debido al ataque de CRIME / BREACH, ¿es correcto?
Leí que esto debería evitarse debido al ataque de CRIME / BREACH, ¿es correcto?
Depende.
El ataque CRIME ya está mitigado en los navegadores actuales porque no utilizan la compresión TLS y tienen un manejo especial de los contextos en HTTP / 2.0. BREACH solo es relevante en el contexto de la compresión de nivel HTTP si las dos condiciones siguientes se aplican al mismo tiempo (para citar enlace ):
Si no se aplica ninguno o solo uno de estos, puedes usar gzip sin ser afectado por BREACH. Esto significa que es seguro usarlo para cualquier página estática o para cualquier página que no incluya secretos como tokens CSRF (esos son los secretos que el atacante quiere extraer).
También el atacante necesita varias solicitudes al mismo sitio y debe poder ver cómo cambia el tamaño de los datos transferidos. Entonces, si sus secretos cambian todo el tiempo o si el sitio cambia (como al agregar un relleno aleatorio con un tamaño aleatorio), el atacante no podrá usar la BREACHO. Vea también Defensa contra el Ataque de INFRACTO .
gzipping los datos cifrados con SSL eliminan las ventajas de SSL en cierta medida. Sí, gzipping TODO puede abrir su sitio web hasta la vulnerabilidad de BREACH.
Pero todavía puedes agregar algunos recursos para gzipping. Por ejemplo, las imágenes públicas pueden ser comprimidas en formato comprimido o documentos públicos en general. Sin embargo, debe considerar detenidamente si desea "sabotear" su propia protección SSL.
Esto también puede valer la pena leer: enlace
EDITAR: Me gustaría agregar, que al usar SPDY se puede lograr una compresión similar a través de encabezados comprimidos y una negociación / renegociación acortada de las claves. También puede "pre" -comprimir recursos de uso frecuente (pero eso no es exclusivo de SPDY).
El funcionamiento de SSL / TLS y Gzipping es que asigna datos para reducir el tamaño de un paquete de manera predecible y repetible que luego se puede deshacer. Esto no es un problema si las páginas están Estático y no tienen tokens o cookies enviadas con ellos. Esto se debe a que los datos solicitados desde el sitio serán constantemente los mismos y, por lo tanto, el tamaño del paquete no cambiará. Sin embargo, con una página dinámica, el contenido siempre cambia excepto un poco en el CSRF y los datos del usuario. Usando esa información, pueden inyectar datos en una solicitud u organismo. Esto es un problema porque les permite cambiar el contenido del paquete y ver cómo se asigna la compresión. Eventualmente, tienen acceso a ciertas cosas en el paquete, incluidas las cookies, las contraseñas o la información del usuario. Solicitar tokens de falsificación y cualquier otra cosa que haya sido enviada. Debido a esto, se recomienda no usar TLS / SSL para la compresión de datos dinámicos de datos sensitivos porque eventualmente el paquete puede romperse.
Lea otras preguntas en las etiquetas tls compression crime beast gzip