¿Cómo parcheo / soluciono la vulnerabilidad de SSLv3 POODLE (CVE-2014-3566)?

157

Después del ataque BEAST y el error Heartbleed , ahora escuché sobre una nueva vulnerabilidad en SSL / TLS llamada POODLE . ¿Cómo me protejo de ser explotado?

  • ¿Solo se ven afectados los servidores o los clientes?
  • ¿Es esto específico de OpenSSL / GnuTLS?
  • ¿Qué tipo de servicios se ven afectados? ¿Solo HTTPS o también IMAPS, SMTPS, OpenVPN, etc.?

Muéstrame ejemplos sobre cómo evitar esta vulnerabilidad.

gertvdijk
fuente
2
Se puede encontrar más información aquí Vulnerabilidad SSL3 "Poodle"
Braiam
1
@Braiam Sí, lo sé, ¡el brillante Thomas otra vez! Sin embargo, esa es una pregunta y respuesta muy criptográfica. Se supone que estas preguntas y respuestas sobre AU proporcionan información práctica y orientada a Ubuntu. :-)
gertvdijk
10
¿Eh? ¿Cómo espera una solución más práctica que "Si no instala los parches, Níðhöggr devorará su bazo"?
Braiam
2
@Braiam Primero que nada: no hay parche (lee mi respuesta). Creo que Thomas se refiere a los dispositivos en lugar del alojamiento del servidor web DIY-Ubuntu. Los dispositivos como los equilibradores de carga suelen ofrecer actualizaciones de firmware para cambiar la configuración predeterminada u ofrecerán funcionalidad para poder configurarlo. Sin embargo, en Ubuntu todo depende del usuario / administrador.
gertvdijk
En realidad lo hay: los proveedores pueden deshabilitar / eliminar todo el código relacionado con SSLv3, por lo tanto, no es necesario que toque nada.
Braiam

Respuestas:

209

Información de fondo

SSL está diseñado para asegurar el nivel de transporte en Internet. Para 'la web', también conocido como HTTP, lo conocerá como HTTPS, pero también se usa para otros protocolos de aplicación. SSLv2 fue el primer protocolo de seguridad de transporte ampliamente utilizado, pero se encontró inseguro poco después. Los sucesores SSLv3 y TLSv1 son ampliamente compatibles ahora. TLSv1.1 y TLSv1.2 son más nuevos y están ganando mucho soporte también. La mayoría, si no todos los navegadores web lanzados a partir de 2014 tienen soporte para ello.

El reciente descubrimiento de los ingenieros de Google señala que SSLv3 ya no debería usarse (como SSLv2 ha quedado obsoleto hace mucho tiempo). Los clientes que no podrán conectarse a su sitio / servicio probablemente sean muy, muy limitados. CloudFlare anunció que menos del 0.09% de sus visitantes aún dependen de SSLv3.

Solución simple: deshabilitar SSLv3.

¿Ubuntu proporciona alguna actualización?

Sí, a través de usn-2385-1 con la adición de la función SCSV, pero no mitiga el problema por completo ya que no deshabilita SSLv3 y el parche solo funcionará si ambos lados de la conexión han sido parcheados. Lo recibirá a través de sus actualizaciones de seguridad periódicas en su administrador de paquetes.

Por lo tanto, USTED DEBE tomar medidas para deshabilitar SSLv3 (es configurable). Las versiones futuras de clientes / navegadores deshabilitarán SSLv3 muy probablemente. Por ejemplo, Firefox 34 lo hará.

Deshabilitar SSLv3 por completo de manera predeterminada en Ubuntu en el nivel de implementación probablemente romperá algunas cosas también para el uso de SSL que no sea HTTPS, que no es tan vulnerable, por lo que supongo que los mantenedores no harán eso y solo se aplicará este parche SCSV.

¿Por qué la actualización SCSV en OpenSSL a través de usn-2385-1 no mitiga el problema?

Realmente, deje de hacer tales preguntas y solo omita algunos párrafos y desactive SSLv3. Pero bueno, si no estás convencido, aquí tienes:

POODLE muestra que SSLv3 con cifrados CBC está roto, la implementación de SCSV no cambia eso. SCSV solo se asegura de no degradar de algún protocolo TLS a ningún protocolo TLS / SSL más bajo según sea necesario con el ataque Man-in-the-Middle requerido para los casos habituales.

Si tiene que acceder a un servidor que no ofrece TLS en absoluto, sino solo SSLv3, entonces su navegador realmente no tiene otra opción y tiene que hablar con el servidor usando SSLv3, que es vulnerable sin ningún ataque de degradación.

Si tiene que acceder a algún servidor que también ofrece TLSv1 + y SSLv3 (lo que se desaconseja) y desea asegurarse de que un atacante no baje la conexión a SSLv3, entonces tanto el servidor como el cliente necesitan este parche SCSV.

Para mitigar completamente el problema, la desactivación de SSLv3 su final es suficiente y puede estar seguro de que no será degradado. Y no podrá hablar con servidores solo SSLv3.

Bien, entonces, ¿cómo deshabilito SSLv3?

Consulte a continuación las secciones específicas de la aplicación: Firefox, Chrome, Apache, Nginx y Postfix están cubiertos por ahora.

¿Solo se ven afectados los servidores o los clientes?

La vulnerabilidad existe si tanto el servidor como el cliente aceptan SSLv3 (incluso si ambos son capaces de TLSv1 / TLSv1.1 / TLS1.2 debido a un ataque de degradación).

Como administrador del servidor, debe desactivar SSLv3 ahora para la seguridad de sus usuarios.

Como usuario, debe deshabilitar SSLv3 en su navegador ahora para asegurarse cuando visite sitios web que aún admiten SSLv3.

¿Es este navegador OpenSSL / GnuTLS / específico?

No. Es un error de protocolo (diseño), no un error de implementación. Esto significa que realmente no puede parchearlo (a menos que esté cambiando el diseño del antiguo SSLv3).

Y sí, hay una nueva versión de seguridad de OpenSSL , pero lea a continuación (¡ pero realmente necesito el soporte SSLv3 ... por la razón X, Y, Z! ) Sobre por qué es mejor que se concentre en deshabilitar SSLv3 por completo.

¿Puedo eliminar SSLv3 en el nivel de red (firewall)?

Bueno, si, probablemente. Puse esto en una publicación de blog separada para reflexionar y trabajar más. ¡Podemos tener alguna iptablesregla mágica que puedas usar!

Mi publicación de blog: ¿Cómo eliminar SSLv3 en su red usando iptables para POODLE?

¿Es relevante solo para HTTPS o también para IMAP / SMTP / OpenVPN y otros protocolos con soporte SSL?

El vector de ataque actual, como lo muestran los investigadores, funciona con el control del texto sin formato enviado al servidor utilizando Javascript que se ejecuta en la máquina de la víctima. Este vector no se aplica a escenarios que no sean HTTPS sin usar un navegador.

Además, normalmente un cliente SSL no permite que la sesión se reduzca a SSLv3 (teniendo TLSv1 + visto en las capacidades de protocolo de enlace), pero los navegadores quieren ser compatibles con versiones anteriores y lo hacen. La combinación con el control de texto sin formato y la forma específica en que se crea un encabezado HTTP lo hace explotable.

Conclusión: deshabilite SSLv3 para HTTPS ahora , deshabilite SSLv3 para otros servicios en su próxima ventana de servicio.

¿Cuál es el impacto? ¿Necesito revocar y regenerar mi certificado de servidor? (Como con Heartbleed)

No, no necesita rotar sus certificados para esto. La vulnerabilidad expone la recuperación de texto sin formato de los datos de la sesión, no proporciona acceso a ningún secreto (ni la clave de sesión ni la clave de certificado).

Es muy probable que un atacante solo sea capaz de robar los encabezados de texto sin formato como las cookies de sesión para realizar el secuestro de sesión . Una restricción adicional es la necesidad de un ataque MitM completo (activo) .

¿Hay algo más que pueda hacer para mejorar mi configuración SSL en general?

Como usuario, además de deshabilitar SSLv3 en su navegador, en realidad no. Bueno, solo instala las últimas actualizaciones de seguridad.

Para los servidores, siga la guía del servidor TLS de Mozilla . Y prueba con la prueba Qualys 'SSL Labs . Realmente no es tan difícil obtener una calificación A + en su sitio. Simplemente actualice sus paquetes e implemente las recomendaciones de la guía de Mozilla.

Pero realmente realmente necesito soporte SSLv3 ... ¡por la razón X, Y, Z! ¿Ahora que?

Bueno, hay un parche que evita el ataque de degradación de los clientes con capacidad TLSv1, llamado SSLv3 Fallback Protection. Por cierto, también mejorará la seguridad de TLSv1 + (el ataque de degradación es más difícil / imposible). Se ofrece como backport de una versión más reciente de OpenSSL en el aviso de seguridad de Ubuntu usn-2385-1 .

Gran problema: tanto los clientes como los servidores necesitan este parche para funcionar. Por lo tanto, en mi opinión, mientras actualiza clientes y servidores, debería actualizar a TLSv1 + de todos modos.

Sin embargo, por favor, solo retire SSLv3 en su red por ahora. Esfuércese por actualizar los estándares de seguridad y simplemente abandone SSLv3.

Escuché sobre el soporte de SCSV para eliminar el ataque de degradación del protocolo. ¿Lo necesito?

Solo si realmente necesita SSLv3 por alguna extraña razón, pero también mejora la seguridad en TLSv1 +, así que sí, le recomiendo que lo instale. Ubuntu proporciona una actualización para esta característica en usn-2385-1 . Lo recibirá a través de sus actualizaciones de seguridad periódicas en su administrador de paquetes.

Prueba de vulnerabilidad para sitios alojados de forma privada (por ejemplo, intranet / fuera de línea).

Sus servidores son vulnerables simplemente si admiten SSLv3. Varias opciones aquí:

  • Con OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Si la conexión tiene éxito, sslv3 está habilitado. Si falla, está deshabilitado. Cuando falla, debería ver algo como:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Utilizando nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Debería salir ' SSLv3: No supported ciphers found'. Ajuste para su nombre de host / puerto.

  • Usando cipherscan . Clonar / descargar el binario y ejecutarlo:

    ./cipherscan myhostname.tld
    

    Debe no enumerar nada con SSLv3 en la columna 'protocolos'.


Navegador Firefox

Abrir about:config, buscar security.tls.version.miny establecer el valor en 1. Luego, reinicie su navegador para descartar cualquier conexión SSL abierta.

Firefox a partir de la versión 34 en adelante deshabilitará SSLv3 de forma predeterminada y, por lo tanto, no requiere ninguna acción ( fuente ). Sin embargo, al momento de escribir, 33 acaba de ser lanzado y 34 está programado para el 25 de noviembre.


Google Chrome (Linux)

Edite el /usr/share/applications/google-chrome.desktoparchivo, p. Ej.

sudo nano /usr/share/applications/google-chrome.desktop

Edite todas las líneas que empiecen Exec=por incluir --ssl-version-min=tls1.

Por ejemplo, una línea como

Exec=/usr/bin/google-chrome-stable %U

se convierte

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Luego, asegúrese de cerrar completamente el navegador (¡las aplicaciones de Chrome pueden mantener su navegador activo en segundo plano!).

Nota: es posible que deba repetir esta actualización de cada paquete de google-chrome, sobrescribiendo este .desktoparchivo de inicio. Un navegador Google Chrome o Chromium con SSLv3 deshabilitado por defecto aún no se anuncia al momento de la escritura.


Servidor Apache HTTPD

Si está ejecutando un servidor web Apache que actualmente permite SSLv3, deberá editar la configuración de Apache. En los sistemas Debian y Ubuntu, el archivo es /etc/apache2/mods-available/ssl.conf . En CentOS y Fedora, el archivo es /etc/httpd/conf.d/ssl.conf . Deberá agregar la siguiente línea a su configuración de Apache con otras directivas SSL.

SSLProtocol All -SSLv2 -SSLv3

Esto permitirá todos los protocolos excepto SSLv2 y SSLv3.

Mientras lo hace, es posible que desee considerar mejorar la configuración del conjunto de cifrado para su servidor web como se explica en la guía del servidor TLS de Mozilla . Agregar por ejemplo:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Luego verifique si la nueva configuración es correcta (sin errores tipográficos, etc.):

sudo apache2ctl configtest

Y reinicie el servidor, p. Ej.

sudo service apache2 restart

En CentOS y Fedora:

systemctl restart httpd

Más información: documentación de Apache

Ahora pruébelo: si su sitio está disponible públicamente, pruébelo utilizando la herramienta Qualys 'SSL Labs .


Servidor Nginx

Si está ejecutando Nginx, simplemente incluya la siguiente línea en su configuración entre las otras directivas SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Mientras lo hace, es posible que desee considerar mejorar la configuración del conjunto de cifrado para su servidor web como se explica en la guía del servidor TLS de Mozilla . Agregar por ejemplo:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

Y reinicie el servidor, p. Ej.

sudo service nginx restart

Referencia: documentación de Nginx

Ahora pruébelo: si su sitio está disponible públicamente, pruébelo con la herramienta SSL Labs de Qualys .


Servidor web Lighttpd

Las versiones Lighttpd> 1.4.28 admiten una opción de configuración para deshabilitar SSLv2 y v3. Las versiones de Lighttpd anteriores a 1.4.28 le permiten deshabilitar SSLv2 SOLAMENTE. Tenga en cuenta que Ubuntu 12.04 LTS y versiones anteriores se instalan en el mejor lighttpd v1.4.28 y, por lo tanto, una solución simple no está disponible para esas distribuciones. Por lo tanto, esta solución solo debe usarse para versiones de Ubuntu superiores a 12.04.

Para Ubuntu versión 12.04 o Debian 6, hay un paquete lighttpd actualizado disponible en el repositorio de openSUSE: http://download.opensuse.org/repositories/server:/http/Debian_6.0

El paquete está destinado a Debian 6 (squeeze) pero también funciona en 12.04 (preciso)

Edite su /etc/lighttpd/lighttpd.confpara agregar las siguientes líneas después de la ssl.engine = "enable"directiva

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Luego, debe reiniciar el servicio lighttpd con a sudo service lighttpd restarty realizar una prueba de reconocimiento ssl3 como se describe en las secciones anteriores para asegurarse de que el cambio se implementó con éxito.

Tomado de http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .


Postfix SMTP

Para 'SSL oportunista' (la política de cifrado no se aplica y también es aceptable), no necesita cambiar nada. Incluso SSLv2 es mejor que simple, por lo que si necesita proteger su servidor, debería usar el modo 'SSL obligatorio' de todos modos.

Para el modo 'SSL obligatorio' ya configurado, simplemente agregue / cambie la configuración smtpd_tls_mandatory_protocols para conexiones entrantes y smtp_tls_mandatory_protocols para conexiones salientes:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Opcionalmente, si también desea deshabilitar SSLv3 para el cifrado oportunista (aunque sea innecesario como se explicó anteriormente), hágalo así:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

y reinicie Postfix:

sudo service postfix restart

Enviar correo

(Edición no verificada por usuario anónimo, no me siento cómodo con Sendmail, verifíquelo).

Estas opciones se configuran en la LOCAL_CONFIGsección de susendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Palomar

En Dovecot v2.1 +, agregue lo siguiente a su /etc/dovecot/local.conf(o un nuevo archivo /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

y reinicie Dovecot:

sudo service dovecot restart

Para versiones anteriores, tendrá que parchear el código fuente .


Courier-imap (imapd-ssl)

Courier-imap permite SSLv3 por defecto en Ubuntu 12.04 y otros. Debe deshabilitarlo y usar STARTTLS en su lugar para forzar TLS. Edite su /etc/courier/imapd-sslarchivo de configuración para reflejar los siguientes cambios

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Servidor HAProxy

SSL es compatible con HAProxy> = 1.5.

Edite el /etc/haproxy.cfgarchivo y encuentre su bindlínea. Anexar no-sslv3. Por ejemplo:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Referencia: documentación de HAProxy


OpenVPN

Parece no verse afectado ( fuente ).

OpenVPN usa TLSv1.0 o (con> = 2.3.3) opcionalmente TLSv1.2 y, por lo tanto, POODLE no lo afecta.


Marioneta

Puppet usa SSL sobre HTTPS pero no lo usan los clientes de 'navegador', solo los agentes Puppet que no son vulnerables al vector de ataque que se muestra. Sin embargo, se recomienda deshabilitar SSLv3.

Mi recomendación es usar el módulo Puppet stephenrjohnson / puppetmodule para configurar su Puppet master en el que maté SSLv3 hace algún tiempo.

gertvdijk
fuente
77
Esta respuesta se creó muy rápidamente después del lanzamiento público de la vulnerabilidad. Todavía puede haber errores allí, como siempre, siéntase libre de editar / mejorar.
gertvdijk
1
La configuración de Nginx no debería tener dos puntos después de la directiva ssl_protocols
Michelle
1
Muy bien, para Firefox, creo que esto es lo que está sucediendo.
fuglede
44
Esta publicación de blog de Mozilla Security sugiere instalar este complemento en lugar de ajustar las preferencias manualmente.
legoscia
1
@muru Aquí hay un comienzo para eliminar SSLv3 en el nivel de firewall. blog.g3rt.nl/take-down-sslv3-using-iptables.html
gertvdijk
4

Puede que no sea ubuntu específico, sino con el fin de evitar la vulnerablity caniche en Node.js puede establecer el secureOptionsque require('constants').SSL_OP_NO_SSLv3cuando se crea un servidor https o TLS.

Consulte https://gist.github.com/3rd-Eden/715522f6950044da45d8 para obtener información adicional

3rdEden
fuente
1
En mi opinión, no debería exponer HTTP (S) con Node / Python / Ruby ni nada de eso directamente. Coloque un HTTPd decente delante de él como Apache / Nginx / ...
gertvdijk
Sí, no deberías estar exponiendo directamente. Los idiomas no son tan buenos con tcp layer HTTP, pero son muy buenos para hacer sockets. Deje que nginx lo lea desde un socket. :-)
jrg
44
Esto no merecía un voto negativo. Hay muchos casos en los que se usa tls además de alojar un servidor http.
psanford
@gertvdijk & jrg Node.js no es un idioma. Es un marco para construir aplicaciones de red escalables. Y como usted dice que debe poner Node.js detrás de un servidor Apache (e incluso llamarlo "decente") ya deja en claro que no tiene absolutamente ninguna idea de lo que está hablando. Afirmar que no son buenos con tpc / http es obviamente un prejuicio personal. Por favor, manténgase en el tema en lugar de tecnología de votación infantil que no entiende.
3rdEden
@ 3rdEden Bueno, tal vez mi comentario fue un poco generalizador, pero aquí hay algunas notas que me gustaría hacer. 1) No voté en contra, 2) mi comentario fue un suave 'IMO', 3) Quizás es solo mi experiencia en seguridad, pero he aprendido que no se debe exponer un marco de aplicación directamente al 80/443 al mundo en producción. (a menos que sea para fines de demostración). 4) No veo cómo su publicación es una 'respuesta' a la pregunta para el visitante general de Ask Ubuntu; es muy, muy específico para un determinado caso específico de implementaciones de Node.js.
gertvdijk
0

La "solución" para el servicio de mensajería desactiva tls 1.1 y tls 1.2. No parece haber una manera de ejecutar el servicio de mensajería con tls 1.1 o superior. Un escaneo PCI en su servidor puede volver con la recomendación:

Configure los servidores SSL / TLS para usar solo TLS 1.1 o TLS 1.2 si es compatible. Configure los servidores SSL / TLS para que solo admitan conjuntos de cifrado que no utilizan cifrados de bloque.

PrgWiz
fuente
-1

Dado que la vulnerabilidad de POODLE es una falla de diseño en el protocolo en sí y no un error de implementación, no habrá parches. La única forma de mitigar esto es deshabilitar SSLv3 en el servidor apache. Agregue las líneas siguientes en ssl.conf y realice un reinicio apache elegante.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
Lal Krishna
fuente
1
-1 por incluir RC4 y ECDSA no funcional ya que la mayoría de las personas tienen certificados RSA. Simplemente lea sobre cómo configurar su servidor correctamente. wiki.mozilla.org/Security/Server_Side_TLS
gertvdijk
2
@gertvdijk Estoy de acuerdo con usted sobre RC4, pero no está de más incluir las suites ECDSA. Es inofensivo si solo tiene un certificado RSA y le ahorra la molestia de arreglar su configuración si luego obtiene un certificado ECDSA.
Matt Nordhoff
@MattNordhoff Lo suficientemente justo, pero lo que quiero decir es que no quedan muchos cifrados para una configuración basada en un certificado RSA regular. Funcionará en la mayoría de los navegadores, pero uno puede enfrentar problemas de compatibilidad.
gertvdijk
Definitivamente deshacerse de RC4 de esta lista, eso no es seguro. Quédate con el resto si puedes. 3DES es débil, pero lo he activado en un lugar en particular por compatibilidad. Odio hacerlo ya que es débil, pero al menos no está realmente roto ...
Brian Knoblauch