¿Se puede habilitar la compresión TLS en sitios CDN de terceros que no tienen autenticación?

Question

¿Se puede habilitar la compresión TLS en sitios CDN de terceros que no tienen autenticación?

#1 de Thomas Pornin (6 votos)

3

En esta respuesta, @Thomas Pornin habla sobre cómo remediar el ataque por CRIMEN y dice:

(Es una pena tener que eliminar la compresión SSL, ya que es muy útil para reducir los requisitos de ancho de banda, especialmente cuando un sitio contiene muchas imágenes pequeñas o es Ajax-pesado con muchas pequeñas peticiones, todas comenzando con versiones extremadamente similares de un mamut Encabezado HTTP Sería mejor si el modelo de seguridad de JavaScript. fue arreglado para evitar que códigos maliciosos envíen solicitudes arbitrarias a un servidor bancario; Sin embargo, no estoy seguro de que sea fácil.

Supongamos que mi sitio web sirve contenido de dos URL de HTTPS: secure.company.com y las imágenes se alojarán en cdn.differentTLD.net . Tenga en cuenta que estoy usando diferentes dominios, por lo que no se enviarán ni validarán cookies de autenticación. También asuma que este CDN contiene archivos estáticos y no se realizará ninguna autenticación.

¿Es seguro habilitar la compresión TLS solo para el CDN?

Entiendo que @ D.W. y la respuesta de @ PulpSpy puede inferir qué archivo se está descargando en función de su publicación a continuación.

Dicho esto, ¿se puede exponer un "secreto" de TLS de nivel inferior fuera de los datos que se encuentran en el protocolo HTTP? (En el ataque por CRIMEN parece que solo hablamos de obtener la cookie en el encabezado)
¿Se pueden usar los datos obtenidos de un exploit CRIME contra el CDN contra el otro dominio?

tls exploit defense

pregunta random65537 03.12.2012 - 14:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls exploit defense

¿Existen vectores de ataque especiales para las bases de datos estadísticas? ¿Puede STARTTLS proteger los correos electrónicos entre dos organizaciones?

score 6 · Accepted Answer

Las vulnerabilidades relacionadas con la compresión tienen que ver con fugas : lo que el atacante puede aprender sobre los datos intercambiados, según la longitud de los datos . Tiene sentido solo para datos confidenciales; En el caso de CRIME, los datos confidenciales son las cookies que el cliente envía al servidor de destino a lo largo de su solicitud.

Si tiene un servidor que no intercambia nada secreto, en particular ningún valor de cookie, entonces no hay datos para filtrar, por lo tanto, no hay problema. Tenga en cuenta que esto no está restringido a cookies : si se envían algunas solicitudes secretas al servidor (p. Ej., Respuesta a un formulario de inicio de sesión con contraseña incorporada), el atacante podría intentar usar la compresión entre esa información y la suya. solicitud falsificada, ya que las solicitudes sucesivas al mismo servidor tienden a reutilizar la misma conexión (la compresión de nivel TLS abarca todo el flujo de datos, ajeno a los límites de solicitud HTTP). Estamos hablando de un servidor al que no se envía ningún dato secreto, y del cual no se obtiene ningún dato secreto. Debemos asumir que no solo las imágenes son datos públicos, sino que la imagen que se descarga es también información pública.

Tenga en cuenta que habilitar la compresión de nivel TLS no le comprará mucho de todos modos. Los navegadores existentes ya no admiten esa compresión y las imágenes ya están comprimidas.