¿Es un requisito también deshabilitar SSL v2 y cifrados débiles en las PC clientes? He visto bastantes publicaciones para deshabilitarlas en los servidores, pero nada acerca de una PC cliente habitual, por ejemplo, con Windows XP o Windows 7.
Es posible que desee leer las tres excelentes respuestas a la pregunta ¿Cómo funciona SSL , donde se explica todo? , pero en pocas palabras, el servidor seleccionará el conjunto de cifrado (y la compresión) que se usará durante el protocolo de enlace SSL / TLS, después de que reciba los conjuntos de cifrado admitidos del cliente. Dado que eliminó la compatibilidad con ciertos conjuntos de cifrado débiles en el extremo de su servidor, no se pueden seleccionar para el cifrado de transporte SSL / TLS, incluso si son compatibles con el cliente.
Editar para agregar: Como lo mencionó @DavidHoelzer en el comentario a continuación, no todos los sitios web se han movido a TLS, y no quiere castigar a sus usuarios por eso. Incluso los conjuntos de cifrado más débiles son mejores que ninguno en absoluto, si elimina el soporte para ellos en los clientes. Es muy probable que sus usuarios aún usen esos sitios web, incluso si no pudieran conectarse al host mediante HTTPS, y terminaran optando por HTTP, exponiéndolos a muchas más amenazas en el proceso. En resumen, no lo recomendaría.
En SSL "normal", el cliente anuncia lo que admite (versiones, algoritmos) y el servidor responde con lo que se utilizará para la conexión. Sin embargo, hay algo especial con SSLv2. Si:
ClientHello en formato SSLv2, y luego, la negociación del algoritmo sigue el estilo SSLv2 en el que tanto el cliente como el servidor envían su lista de algoritmos compatibles, y el cliente elige.
En cualquier caso , no habrá un algoritmo o versión de protocolo que se usará a menos que tanto el cliente como el servidor acepten usarlos. Además, al menos con SSLv3 y ulterior, el cliente envía una lista ordenada de algoritmos preferidos, y no colocará primero los conjuntos de cifrado débiles. Por lo tanto, en la práctica, el cliente y el servidor aceptarán usar SSLv2 y / o un conjunto de cifrado débil solo si ambos los admiten y no hay una mejor versión o conjunto de cifrado que ambos admitan. Así que esto no sucede a menudo; y si sucede , se podría argumentar que SSLv2 o un conjunto de cifrado débil es mejor que no poder conectarse en absoluto.
(Nota: hay un detalle técnico sobre SSLv2, sin embargo. En SSLv2, un atacante puede obligar al cliente y al servidor a acordar un conjunto de cifrado débil incluso si ambos admiten conjuntos de cifrado sólidos. Sin embargo, si ambos clientes y el servidor admite SSLv3 o TLS además de SSLv2, entonces el atacante no puede obligarlos a usar SSLv2. Consulte la sección E.2 de TLS 1.0 .)
Por lo tanto, , no hay un requisito absoluto de deshabilitar SSLv2 en los clientes. Sin embargo, es mejor alejarse de SSLv2 (debería haberse hecho ya hace una década); hay un un RFC sobre ese tema.
Los proveedores de navegadores no han esperado por eso. Por ejemplo, IE 8.0 desactiva el soporte SSL 2.0 de forma predeterminada en el cliente. Se puede volver a habilitar, pero se puede suponer que casi nadie lo hizo y la Web no implosionó. Del mismo modo, Chrome eliminó el soporte de SSL 2.0 desde la versión 10, y las versiones recientes de Firefox tampoco lo admiten. De hecho, podría estar un poco atrasado en la multitud que odia a SSLv2. El mundo se ha movido a SSL 3.0 y TLS.
En cuanto a las suites de cifrado débiles, solo se utilizarán si no hay una mejor opción, y el DES de 56 bits es aún mejor que ningún cifrado, por lo que les digo: déjelos vivir.
Harías esto por aplicación cliente.
por ejemplo en el antiguo Firefox
No pude encontrar una manera de deshabilitar sslv2 en Firefox moderno. Creo que se ha ido.
En Chrome, esta discusión sugiere que sslv2 está deshabilitado de forma predeterminada:
Y esta pregunta tiene una respuesta sobre IE5.5, IE6 e IE7
No pude encontrar información sobre el navegador web Safari.
Lea otras preguntas en las etiquetas tls protocols cipher-selection server client-side