He leído que BREACH fue un ataque de compresión de canal lateral contra TLS, sin embargo, se centra en la compresión de respuesta HTTP. Si un sitio ha inhabilitado la compatibilidad con la compresión TLS, ¿significa que aún puede verse comprometido por un ataque como CRIMEN, INCUMPLIMIENTO, etc., utilizando compresión HTTP / respuestas HTTP?
Además, ¿este tipo de ataque requiere soporte de compresión tanto del navegador como del servidor para tener éxito?
De la BREACH página de Wikipedia:
BREACH explota la compresión en el protocolo HTTP subyacente. Por lo tanto, desactivar la compresión TLS no hace ninguna diferencia a BREACH, que aún puede realizar un ataque de texto simple elegido contra la carga útil HTTP.
Sin embargo, CRIME se puede mitigar eliminando la compatibilidad con la compresión TLS.
En TLS, el algoritmo de compresión se negocia entre el cliente y el servidor. El cliente propone una lista de algoritmos adecuados, y el servidor elige uno de ese conjunto. Tienen que ponerse de acuerdo sobre un algoritmo, y si no lo hacen, la conexión falla. Entonces para CRIME requeriría soporte de compresión desde ambos extremos.
Sin embargo, como se indicó anteriormente para BREACH, se explota la compresión HTTP, no la compresión TLS. Compresión HTTP :
Los datos HTTP se comprimen antes de enviarlos 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 un método de compresión compatible descargarán los datos sin comprimir.
En base a esto, tanto el cliente como el servidor tendrían que admitir algún tipo de compresión (generalmente GZIP o DEFLATE) para que este ataque funcione.
BREACH y CRIME no comprometen los sitios, ya que son ataques a clientes , no a servidores. El servidor todavía está involucrado en eso, por ejemplo, la compresión TLS no se utilizará a menos que el servidor esté de acuerdo; de manera que, incluso si el ataque CRIME se dirige al cliente, el servidor puede negarse a usar la compresión y esto protege indirectamente a los clientes vulnerables.
Ambos ataques se relacionan con el mismo principio general: el cifrado oculta el contenido de los datos, pero no el tamaño de los mismos. La compresión hace que el tamaño de los datos dependa de los contenidos de los datos. Por lo tanto, la compresión puede filtrar información sobre los contenidos de datos que el cifrado no protegerá. Si el atacante está en una posición en la que puede inyectar algunos datos propios junto con los datos que intenta recuperar (formalmente, a ataque de texto sin formato elegido ), luego gana.
CRIME fue una aplicación de este concepto a la compresión de nivel TLS en un contexto web. La Web permite Javascript, que puede ser hostil y emitir solicitudes (sujeto a algunas restricciones en el caso de solicitudes entre sitios); Así es como el atacante puede lograr una situación de CPA. La desactivación de la compresión a nivel TLS soluciona el problema, y en realidad no se podía solucionar de ninguna otra manera, ya que la fuga de datos inducida por la compresión es un concepto muy genérico. Tenga en cuenta que la compresión a nivel HTTP no hace nada a favor o en contra de CRIME, ya que CRIME se concentra en el encabezado (la ruta de la solicitud y la cookie).
BREACH es otra aplicación del concepto, esta vez en compresión a nivel HTTP. La compresión a nivel HTTP se realiza solo en los cuerpos de solicitud, no en los encabezados HTTP, por lo que BREACH es más difícil de lograr (mientras CRIME funcionaba siempre que estaba involucrada una cookie, BREACH requiere que el contenido del sitio sea susceptible de alguna manera al ataque). Deshabilitar la compresión TLS no hará nada a favor o en contra de BREACH.
De todos modos, cualquier máquina aplicará la compresión (ya sea para TLS o solo para los cuerpos de solicitud / respuesta HTTP) si está razonablemente seguro de que la máquina en el otro extremo de la conexión lo entenderá, debido a algunos indicación previa a tal efecto (en el mensaje TLS ClientHello para TLS, en un encabezado de solicitud para HTTP). No habrá compresión, por lo tanto, ningún ataque, a menos que tanto el cliente como el servidor lo admitan y acepten su uso. Así es como se puede aplicar la mitigación de ataques a clientes en el servidor.
Lea otras preguntas en las etiquetas attacks encryption tls http attack-vector