¿Existe algún riesgo al servir activos estáticos a través de un protocolo SSL comprimido de un dominio de terceros?

Primero, tenga en cuenta que no está utilizando la compresión de nivel SSL, sino la compresión de nivel HTTP: hay un encabezado HTTP que describe el modo de compresión. La compresión se aplica solo al cuerpo de la respuesta HTTP, es decir, al archivo colors.min.js , con exclusión de cualquier otra cosa, en particular a las cookies HTTP u otros valores similares.

no es segura cuando se aplica en valores secretos y el atacante tiene la posibilidad de obtener muchos ejemplos de datos comprimidos con el mismo secreto repetido en todos ellos, pero también con variantes. En particular, cuando el atacante inserta los datos elegidos por él dentro de la secuencia de datos comprimida.

En el caso que muestra, no hay datos secretos en absoluto; La secuencia de datos que se comprime es una pieza completamente pública de Javascript. La compresión se abusa de los ataques por su capacidad de filtrar información sobre los datos contenidos a través de los datos length (y la longitud no está protegida por ningún cifrado posterior ). Si los datos de origen son completamente públicos, entonces no hay información para filtrar, y por lo tanto no hay ataques.

(Aunque colors.min.js es público, todavía quieres superar el protocolo HTTPS, no por confidencialidad sino por integridad : quieres evitar que los atacantes activos cambien el Javascript código sobre la marcha.)

Incluso si los datos comprimidos no fueran públicos, un archivo estático aún podría mostrarse comprimido, porque la compresión es determinista y generaría la misma secuencia de bytes cada vez, por lo tanto, en particular, siempre la misma longitud, nada Para aprender por el atacante.