Caniche: ¿Deshabilitar SSL V3 en el servidor es realmente una solución?

He estado leyendo todo el día sobre la vulnerabilidad de Poodle y ahora estoy un poco confundido frente a Seguridad e Ingresos.

Si desactivo SSL V3 en el servidor (SSL V2 y V3 se desactivarán para los clientes de Apache) (navegadores) que no admiten ningún protocolo, pero SSL V3 no podrá conectar HTTPS con el servidor.

Por lo tanto, es una situación en la que tanto el cliente como el servidor deben comunicarse con TLS 1.1 1.2, etc.

Si alguno de ellos usa SSL V3 y el otro no admite versiones inferiores, ¿qué sucede? Sin conexión a SSL.

He visto algunas actualizaciones realizadas en Firefox, tal vez han deshabilitado el SSL V3 en lo que generalmente tenemos que hacer en las opciones. Esto forzará toda la conexión a versiones inferiores y TLS

¿Pero deshabilitar SSL V3 es realmente una solución para este problema?

Primero, aclaremos un poco las cosas:

• TLS reemplazó SSL. TLS 1.0 vino después y es una actualización de SSL 3.0.

  TLS 1.2> TLS 1.1> TLS 1.0> SSL 3.0> SSL 2.0> SSL 1.0

• Las versiones de SSL anteriores a la 3.0 han tenido graves vulnerabilidades de seguridad durante un tiempo y están deshabilitadas / no son compatibles con los clientes y servidores modernos. SSL 3.0 probablemente seguirá el mismo camino pronto.

• De los protocolos utilizados actualmente, "Poodle" afecta más gravemente a SSL 3.0, donde no hay forma de mitigarlo. Existe un ataque similar contra algunas implementaciones de TLS 1.0 y 1.1 que permite la especificación: asegúrese de que su software esté actualizado.

Ahora, la razón por la que "Poodle" es un riesgo incluso con clientes y servidores modernos se debe a la implementación de un mecanismo de respaldo por parte de los clientes. No todos los servidores admitirán las últimas versiones, por lo que los clientes probarán cada versión en orden, desde la más reciente hasta la menos reciente (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0) hasta que encuentre una que el servidor admita. Esto sucede antes comience la comunicación cifrada, por lo que un atacante man-in-the-middle (MITM) puede obligar al navegador a recurrir a una versión anterior, incluso si el servidor admite una versión superior. Esto se conoce como un ataque de degradación de protocolo.

Específicamente, en el caso de "Poodle", siempre que el cliente y el servidor admitan SSL 3.0, un atacante MITM puede forzar el uso de este protocolo.

Entonces, cuando deshabilita SSL 3.0, esto tiene dos efectos:

• No se puede engañar a los clientes que admiten versiones superiores para que recurran a la versión vulnerable ( TLS Fallback SCSV es un nuevo mecanismo propuesto para evitar un ataque de degradación del protocolo, pero no todos los clientes y servidores lo admiten todavía). Esta es la razón por la que desea deshabilitar SSL 3.0. La gran mayoría de sus clientes probablemente caigan en esta categoría, y esto es beneficioso.

• Los clientes que no admiten TLS en absoluto (como han mencionado otros, IE6 en XP es prácticamente el único que todavía se usa para HTTPS) no podrán conectarse a través de una conexión cifrada. Es probable que sea una porción menor de su base de usuarios, y no vale la pena sacrificar la seguridad de la mayoría que está actualizada para atender a esta minoría.

Tu valoración es correcta. Los clientes necesitarán usar protocolos más nuevos para conectarse a su servidor una vez que deshabilite SSL 3. El protocolo SSL 3 es defectuoso y no habrá "parche". Deshabilitar SSL 3 es la única solución.

En este punto, muchos sitios han deshabilitado SSL 3, por lo que es prácticamente inevitable que los usuarios de navegadores antiguos necesiten actualizarse. Suponiendo que está registrando cadenas de agente de usuario, puede revisar sus registros y tomar una decisión informada sobre la desactivación de SSL 3. Creo que es probable que solo un pequeño porcentaje de los visitantes de su sitio esté usando navegadores que no podrían manejar los protocolos más nuevos.

[fwiw - cloudflare informa que 1.12% de los usuarios son usuarios de IE6 XP dependiendo de SSLv3]

Sí, deshabilitar SSL3 hará que los usuarios que no admitan TLS no puedan acceder a su sitio web.

Sin embargo, desde un punto de vista práctico, observe qué navegadores entran en esa categoría. Chrome y Firefox son compatibles con TLS e incluso dejarán de admitir SSL3 por completo debido a este error. IE lo ha soportado desde IE7. El único navegador que no tiene soporte, pero que todavía se usa a escala global, es IE6, y la única razón por la que todavía se usa es por 2 razones:

1. Cualquier persona con una versión crackeada de XP y sin forma de usar Chrome o Firefox;
2. Cualquier persona en una política corporativa o gubernamental con restricciones con respecto a la elección del navegador.

En ambos casos, se usa IE6 porque es el navegador predeterminado de Windows XP que viene con la instalación original. Además, la única razón por la que IE6 todavía tiene una cuota de mercado global (pequeña) es por los muchos usuarios en China.

Entonces, larga historia corta: aquí hay 3 preguntas:

1. ¿Tiene una importante base de usuarios chinos?
2. ¿Su sitio web proporciona soporte para IE6, a pesar de que está anticuado y roto?
3. ¿Su sitio web es un producto utilizado por un gobierno o una corporación con restricciones de elección de navegador?

Si alguno de estos 3 es cierto, tendrá que encontrar una solución alternativa. Si las 3 son falsas, simplemente desactívelas y termine con ellas. Y si necesita una solución alternativa, ¿es muy difícil convencer a esa pequeña parte de su base de usuarios que todavía usa IE6 para cambiar de un navegador de 13 años?

Mencionas " Apache " y " navegadores " " en su pregunta, pero el título es más general.

Como señalan Evan y otros, el problema está casi resuelto para HTTPS. Pero hay una serie de otros protocolos que un servidor podría encriptar, y el soporte TLS es mucho más pobre entre esa base de clientes (como descubrí esta mañana, al ordenar "no SSL3" en un servidor IMAP / S).

Así que me temo que la respuesta es " depende de los servicios que encriptes y el soporte del cliente para TLS entre tu base de usuarios ".

Editar : sí, ese era mi punto, aunque me alegro de que estés de acuerdo. La desactivación de sslv3 se realiza servicio por servicio. Por ejemplo, la forma de apagarlo en dovecot es poner

ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

en dovecot.conf. El mayor problema es que, si bien la mayoría de los navegadores son tolerantes a la pérdida de sslv3, los clientes de otros servicios parecen ser mucho menos tolerantes. Esta mañana rompí con la mitad de mis usuarios cuando lo apagué en dovecot; Los teléfonos Android con correo K-9 y Outlook en Win7 son dos de los que estoy seguro, pero puedo ver en mis registros que había más.

Desactivar SSLv3 todavía no es solo una solución válida, es la única solución; pero va a doler

Edición 2 : gracias a dave_thompson_085 por señalar que deshabilitar los cifrados SSLv3 en dovecot deshabilita no solo el protocolo SSLv3, sino también TLSv1.0 y TLSv1.1, ya que no tienen cifrados que el protocolo anterior no tiene. Dovecot (al menos, versiones anteriores, que incluyen la que estoy ejecutando) parece carecer de la capacidad de configurar protocolos en lugar de conjuntos de cifrado. Esto probablemente explica por qué hacerlo rompió con tantos clientes.

Deshabilitar SSLv3 es la mejor solución, pero no estoy de acuerdo con que sea la única solución. Como describe CloudFlare, el uso de SSLv3 es muy bajo , por lo que la mayoría de los administradores no deberían tener problemas para desactivarlo.

Si tiene un requisito especial para SSLv3, quizás deba admitir IE6 en Windows XP o deba admitir software muy antiguo, hay otra forma de mitigarlo.

La forma de mitigarlo y mantener SSLv3 es utilizar RC4 y admitir TLS Fallback SCSV, que es provisto por OpenSSL 1.0.1j. En la publicación de Qualys en Poodle , RC4 es el "cierto cifrado de flujo inseguro cuyo nombre nadie quiere mencionar".

Esto es lo que google hace en mail.google.com, y también lo describen en la entrada del blog: http://googleonlinesecurity.blogspot.se/2014/10/this-poodle-bites-exploiting-ssl-30.html

Falta un detalle en la conversación, según la pregunta original, puede ser una buena idea anotarlo. TLS 1.0 también se conoce como SSL 3.1, por lo que el póster original debe mirar su configuración, ¿está ejecutando v3.0 o v3.1?

Como con la mayoría de las cosas, la respuesta es "depende". El único navegador en cualquier tipo de uso "común" que no es compatible con TLS es IE6. Desafortunadamente, varios informes dicen que IE6 puede ser tanto como un pequeño porcentaje de las solicitudes HTTP globales (ver: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html ) . La buena noticia, si estás en América del Norte, es que es relativamente poco común en los Estados Unidos. Para estar seguro, debe mirar la estadística de agente de usuario de sus registros de www. En mi caso, había tan pocas huellas digitales IE6 ua que supuse que todas eran de herramientas de prueba.

Puede probar su (s) sitio (s) web con el probador de ssllab para ver cómo reaccionan varios agentes.

https://www.ssllabs.com/ssltest/

TL; DR: SSLv3 está muerto; larga vida a TLS.