¿Por qué los navegadores sondean y retroceden (o, por qué SSL_MODE_SEND_FALLBACK_SCSV)?

4

He estado siguiendo POODLE y la extensión SSL_MODE_SEND_FALLBACK_SCSV TLS. Nunca le presté mucha atención, pero parece que SSL_MODE_SEND_FALLBACK_SCSV es necesario para clientes como los navegadores que intentan usar una versión particular del protocolo SSL / TS, y luego retroceden a una versión menor en caso de falla.

SSL / TLS efectivamente tiene una versión 'min' y 'max' configuradas durante el protocolo de enlace, y esos valores se MACed para que los ataques de degradación se remedien.

Me parece que el software cliente cuya sonda y respaldo están defectuosos, ya que sufren ataques de baja calificación. Si usaran el protocolo tal como fue diseñado, este problema en particular no existiría y no habría necesidad de SSL_MODE_SEND_FALLBACK_SCSV .

Además, SSLv3 ahora se considera inseguro, por lo que SSL_MODE_SEND_FALLBACK_SCSV no es necesario ya que nadie lo usará (como si Loren Weith no enumeró los problemas con SSLv3 con la suficiente claridad).

¿Por qué el software del cliente, como los navegadores web, sondea una versión de protocolo en particular y el respaldo en caso de falla?

    
pregunta jww 17.10.2014 - 19:16
fuente

2 respuestas

13

El software del cliente que es susceptible a los ataques de degradación es defectuoso, en el sentido de que a propósito hace cosas fuera del estándar para admitir software de servidor que es defectuoso.

Normalmente, el cliente anuncia (en el ClientHello ) su número de versión de protocolo más alto admitido (por ejemplo, "3.2" que significa "TLS 1.1") y luego el servidor responde (en el ServerHello ) con la versión del protocolo que será utilizado para esa conexión. Por lo tanto, el comportamiento teórico cuando un cliente reciente habla con un servidor antiguo es el siguiente:

  • El cliente dice: "Yo apoyo hasta 3.2".
  • El servidor piensa: "Mmh, no tengo idea de lo que puede ser SSL 3.2, pero sé que SSL 3.0 y 3.0 es inferior a 3.2".
  • El servidor responde: "Usaremos 3.0".

Sin embargo, en algunos casos raros en la práctica, el software antiguo del servidor no solo es antiguo sino que está dañado; y las cosas van de esa manera:

  • El cliente dice: "Yo apoyo hasta 3.2".
  • El servidor piensa: "OMG 3.2 NO TENGO IDEA, LO QUE ES QUE DEBO COMPROMETAR CON SEPPUKU HONORABLE". El servidor cierra la conexión de manera abrupta.
  • El cliente piensa: "Mmh, el servidor se rompió. Probablemente sea una vieja chatarra. Debo tener paciencia cuando hablo con los ancianos".
  • El cliente se vuelve a conectar y dice: "Admito hasta 3.0".
  • El servidor responde: "Usaremos 3.0".

Cuando las cosas salen así, el hash que se calcula en todos los mensajes de intercambio y se incluye en los mensajes Finished no incluye el hecho de que el cliente podría haber usado un protocolo más nuevo. Al volver a conectar y utilizar una versión anunciada artificialmente inferior, el cliente evita que el sistema de detección de downgrade funcione. Podemos decir que el problema ocurre porque los clientes no actúan como deberían, pero lo hacen porque hay servidores implementados que están aún más dañados. Puede ser difícil culpar sin ambigüedades aquí.

Los atacantes que desean forzar una degradación del protocolo abusan de ese sistema al eliminar la primera conexión con un paquete RST bien colocado, para simular un servidor senil que no puede tolerar ninguna de estas conversaciones recientes sobre una versión de protocolo diferente a la 3.0.

El TLS Fallback Signaling Cipher Suite Value (SCSV) para prevenir ataques de degradación de protocolo , actualmente en borrador, es un método para escabullirse en el mensaje de intercambio de información: la información que el cliente realmente admite mejor que SSL 3.0, de una manera que no hará que los servidores antiguos dispersen sus cerebros electrónicos. en el piso; toma la forma de un identificador de conjunto de cifrado especial (se basa en la idea de que incluso los servidores antiguos no se volverán locos cuando la lista de conjuntos de cifrado admitidos incluya uno que no conocen). Por supuesto, el mecanismo ofrece protección solo si ambos el cliente y el servidor lo saben (el cliente debe poner el identificador especial, y el servidor debe reconocerlo y decirse a sí mismo: "¿cómo es posible? ¿Está haciendo SSL 3.0 si el cliente conoce una versión más reciente? Esto es sospechoso ... ").

Otra opinión sobre el tema es que si SSL 3.0 es débil y no debería usarse en absoluto, entonces la única práctica sensata es rechazarlo por completo. Necesita una protección contra los ataques de downgrade solo si todavía está listo para usar SSL 3.0 en caso de que el servidor realmente no admita nada más. Si teme las consecuencias de usar SSL 3.0, nunca debería aceptar usarlo. Esto es considerado como potencialmente extremo; Un compromiso más suave puede ser, en el lado del cliente (navegador), mantener una lista explícita de servidores para los cuales se tolerará SSL 3.0. Esta lista, configurable por el propio usuario, combina la posible tolerancia de algunos sistemas heredados, y una dosis saludable de señalar con el dedo los sistemas cuya miseria debería haber terminado hace mucho tiempo.

Editar: vea los comentarios allí ; esta es una discusión entre los mantenedores de Firefox donde discuten exactamente las consecuencias de eliminar el soporte SSL 3.0 por completo, y varias alternativas.

    
respondido por el Thomas Pornin 17.10.2014 - 19:39
fuente
1

Versión corta: la interoperabilidad apesta.

Versión larga:

Actualmente hay cuatro variantes de SSL / TLS de uso común:

  • SSLv3 (1996)
  • TLSv1.0 (1999)
  • TLSv1.1 (2006)
  • TLSv1.2 (2008)

Cada protocolo admite una variedad de cifrados. Los protocolos más antiguos tienen un soporte de cifrado más amplio y uniforme. Los protocolos más nuevos pueden implementar subconjuntos más pequeños de los cifrados disponibles, y diferentes clientes y servidores pueden implementar subconjuntos diferentes en todos los casos. A medida que pasa el tiempo, se vuelve más obvio qué cifrados son comunes, y las implementaciones apoyarán cada vez más los cifrados comunes (una especie de pollo y huevo, todos juntos).

Por lo tanto, es más probable que las versiones de protocolo más antiguas compartan un subconjunto común de cifrados aceptables.

La idea del respaldo es que dos sistemas pueden intentar hablar juntos en TLSv1.2, pero no pueden ponerse de acuerdo sobre un cifrado. Al decir que está bien retroceder y probar un protocolo más antiguo, las posibilidades de poder negociar una conexión aceptable mejoran. Los clientes pueden intentar la mejor seguridad, pero el respaldo permite la interoperabilidad.

(Y, recuerde, no debería haber ningún protocolo inseguro en la lista. SSLv3 solo tuvo un gran impacto en su seguridad; puede esperar que desaparezca del uso común el próximo año).

    
respondido por el gowenfawr 17.10.2014 - 19:30
fuente

Lea otras preguntas en las etiquetas