Protección de polarización RC4 con relleno en TLS

Question

Protección de polarización RC4 con relleno en TLS

#1 de Thomas Pornin (9 votos)
#2 de D.W. (5 votos)

10

En la respuesta a mi pregunta anterior sobre las vulnerabilidades de RC4 en TLS , Thomas Pornin dio una gran respuesta, en la que dijo:

Una forma de "arreglar" RC4, que se ha sugerido muchas veces, es eliminar los primeros 256 (o 512 o 1536 o lo que sea) bytes de salida, ya que estos son los más sesgados de ellos (los gráficos en las diapositivas mostrar eso con bastante claridad). Pero esto no sería compatible con RC4-tal como lo conocemos

Curioso por esto y un comentar en HN que hace una sugerencia interesante, me pregunto si el navegador ( o incluso un complemento del navegador) puede rellenar solicitudes HTTP, de modo que los primeros 256 bytes (o 512 o lo que sea) son solo un encabezado inútil. por ejemplo

GET / HTTP/1.1
X-Padding-Header: <256 bytes of random text>
Accept: */*
...

Por lo que sé, los encabezados desconocidos se ignoran (?), y esto aseguraría que los primeros bytes en la solicitud sean inútiles (sin valor para adivinarlos) y aleatorios.

¿Es esta una solución tonta que podría crear más daño que bien? ¿O si los navegadores lo van a arreglar, también podrían actualizar a TLS 1.2?

(ps, por supuesto, si la URL en sí contiene información confidencial y es lo suficientemente larga, estará presente en la solicitud antes del encabezado, por lo que esta "protección" no ayudará con esto, pero quizás sea lo suficientemente buena para proteger las cookies) ?)

web-browser tls rc4

pregunta Yoav Aner 13.03.2013 - 09:37

fuente

2 respuestas

5

Esto sería seguro contra todos los ataques que conozco.

Desde una perspectiva de seguridad, no es lo suficientemente equivalente a eliminar los primeros 256 o 512 bytes. Con su propuesta, el atacante tiene un texto sin formato conocido (por ejemplo, de la línea GET y el encabezado X-Padding), mientras que si elimina los primeros 256 bytes, el atacante no recibe texto sin formato conocido en esas posiciones. Teóricamente, si el conocimiento de algunos de los primeros 256 bytes de salida de RC4 permitiera a un atacante recuperar la clave, su esquema sería insuficiente. Sin embargo, no tengo conocimiento de ningún ataque en RC4 de esa forma. En la práctica, todos los ataques conocidos en RC4 dicen que uno o dos de los primeros bytes de salida de RC4 están ligeramente sesgados, por lo que no ocultan el texto sin formato tan bien como quisieras, pero este sesgo no lo hace. Permitir que un atacante deduzca la clave RC4. Entonces, desde la perspectiva de la seguridad, en la práctica, su esquema es probablemente tan bueno como eliminar los primeros 256 bytes de salida RC4.

Sin embargo, desde una perspectiva de rendimiento, acaba de agregar 256 bytes a cada solicitud enviada a través de SSL. Eso es muy malo para el rendimiento. Este problema de rendimiento es probablemente suficiente para matar esta propuesta; Probablemente no sea un candidato viable para el despliegue.

Si los navegadores quieren solucionarlo, sería mucho mejor simplemente actualizar a TLS 1.2 y conjuntos de cifrado más seguros.

respondido por el D.W. 13.03.2013 - 09:46

fuente

Lea otras preguntas en las etiquetas web-browser tls rc4

¿Cómo protege el enmascaramiento de fotogramas de websocket contra el envenenamiento de caché? ¿Cuál es una buena fuente para configuraciones de bases reforzadas?

score 9 · Accepted Answer

Como @ D.W. señala, esto funcionaría - para proteger la cookie . La ruta en sí misma aparece antes de los encabezados, y también puede estar en riesgo si contiene datos confidenciales en un lugar predecible (este no es un caso común en la actualidad, pero la reescritura de URL para la administración de sesiones solía ser popular ).

Una variante se vería así:

GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>

Al elegir X y Y al azar, pero de manera tal que X+Y sea fijo, el emplazamiento de la cookie en el flujo cambiará entre solicitudes, de una manera que los atacantes no puedan detectar (ya que la longitud total del los encabezados son constantes). Si bien no es tan satisfactorio como simplemente eliminar los primeros 256 bytes de la solicitud, esto debería ser suficiente para recuperar el esfuerzo de los ataques basados en sesgos en los miles de millones de solicitudes, en lugar de millones, y podría hacerse con menos de 256 extra. bytes por solicitud (tener X+Y = 32 debería hacer eso).