Necesito deshabilitar los cifrados CBC específicos de SSLv3 como solución temporal a la vulnerabilidad POODLE, ya que existen aplicaciones heredadas que necesitan usar SSLv3. Después de consultar los documentos de OPENSSL, parece que existen cifrados compartidos entre SSLv3 y TLSV1, como:
- SSL_DHE_RSA_WITH_DES_CBC_SHA
- DHE-RSA-DES-CBC-SHA
- TLS_DHE_RSA_WITH_DES_CBC_SHA
- DHE-RSA-DES-CBC-SHA
Mi pregunta es, ¿hay alguna manera de desactivar, por ejemplo?DHE-RSA-DES-CBC-SHAespecíficamente para SSLv3 y ¿esta acción afectará a TLSv1?
Estoy usando nginx, Varnish y Apache con OPENSSL
Respuesta1
Esta configuración debe realizarse en su servidor web. OpenSSL solo le permite especificar cifrados mediante programación, como se dice en esteSE respuesta.
Como dijiste que estás usando Apache y nginx (el caché web Varnish no admite SSL), encontré estas páginas que hablan del mismo asunto, aunque están dirigidas a BEAST:
Éste es sobre elTerminación SSLque permite que el barniz almacene en caché su contenido:
PD muy importante:
PS1: no olvides usarHSTS
PS2: establezca siempre el indicador "Seguro" en las cookies generadas dentro de conexiones cifradas. Olvidar esto es una manera muy fácil de filtrar información a los atacantes.
Respuesta2
La respuesta canónica eshttps://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerabilityy prefiere excluir elprotocoloSSLv3, no cifrados.
Preliminarmente, los dos conjuntos de cifrado distintos que usted nombra utilizan DES original, retrónimoDES único, y soninseguro en TODAS las versiones del protocolo. El DES original fue reemplazado y retirado hace una década. (Más exactamente, FIPS46-3 fue reemplazado por FIPS197 AES en 2001, luego retirado en 2005, y solo DEA triple, NO DEA simple, se volvió a publicar como SP800-67 en 2004 como aprobado pero no como estándar). Están clasificados como BAJOS. en la configuración de cifrado de openssl, y junto con EXPORT (aún menos seguro) y eNULL (totalmente inseguro) deberíannuncaconfigurarse a menos que tenga que lidiar con un sistema seriamente obsoleto que no se puede actualizar, reemplazar o implementar, como quizás uno de los módulos de aterrizaje más antiguos en Marte.
A su pregunta, en realidad no existen cifrados CBC específicos de SSLv3, aunque sí los hay.no-SSLv3. En openssl, la configuración de protocolos y conjuntos de cifrado permitidos es separada y casi independiente; AFAICS, las únicas restricciones son que los cifrados que utilizan las nuevas funciones TLSv1.2 (cifrado autenticado GCM o hashes SHA-2) no se pueden elegir en ningún protocolo anterior, y algunos cifrados se usan en SSLv2 pero no se les asignan códigos SSLv3+ porque ya eran inseguros. en 1996 no se puede utilizar en SSL3+. Inclusosegún los estándares, las únicas diferencias para los cifradosentre SSL3 y TLS1 o 1.1 son:
los cifrados EXPORT de 40 bits fueron eliminados oficialmente en 1.1, pero openssl todavía los admite de todos modos en 1.1 y 1.2 como una extensión. Pero eran y son inseguros y no deberías usarlos a menos que viajes en el tiempo a la década de 1990 y estés sujeto a las restricciones legales enalgunolugares entonces.
TLS1 eliminó el intercambio de claves de Fortezza agregado para apaciguar al gobierno de EE. UU. durante el período de "las criptomonedas son un arma", y nunca fue utilizado por nadie excepto tal vez por la NSA. Openssl no lo implementa encualquierprotocolo.
el primer lote de cifrados ECC enhttps://www.rfc-editor.org/rfc/rfc4492Se aplican oficialmente solo a TLS1+ porque dependen de extensiones en ClientHello yhttps://www.rfc-editor.org/rfc/rfc3546para las extensiones no se pudo modificar SSL3, pero openssl >=1.0.0 (o algo 0.9.8 si se modifica) las implementa en SSL3 al tratar las extensiones como predeterminadas en "sin restricción", pero solo si el par está de acuerdo, qué pares Aparte del reciente opensl deliberadamente nobled probablemente no lo hará. Este es elúnica diferencia de cifrado posiblemente útil.Suponiendo un certificado RSA y una clave privada, puede usar ECDHE-RSA y esperar que solo funcione en TLS1+.
Es por eso que la openssl ciphers -v [$cipherstring]utilidad de línea de comandos muestra SSLv3 como la "versión" para la mayoría de los cifrados; significa SSLv3 Y ARRIBA.
TL-DR:SI sus clientes SSL3 únicamente no negocian cifrados ECC (y la mayoría de los clientes más antiguos probablemente no lo hagan, aunque los más nuevos sí pueden hacerlo) Y TODOS sus clientes TLS1+HACER(lo cual es mucho menos seguro) y suponiendo el caso común de un certificado RSA y una clave privada, podría habilitar ECDHE-RSA-(3DES o AES)-CBC pero deshabilitar DHE-RSA-anything-CBC y RSA-anything-CBC. Esto también le proporciona un secreto directo perfecto.
Si lo desea, también puede habilitar RC4 para todos los SSL3+, con PFS o no, pero también existen preocupaciones al respecto:
- https://security.stackexchange.com/questions/32497/tls-rc4-or-not-rc4
- https://crypto.stackexchange.com/questions/10955/what-stream-cipher-can-we-replace-the-rc4-in-the-ssl/
- http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
¿Sus "aplicaciones heredadas" son web o algo más? Si es web, ¿no puedes conseguir un navegador medio decente? Si no se puede hacer que una aplicación personalizada reenvíe repetidamente los mismos datos confidenciales DESPUÉS de los datos del atacante, en primer lugar, no es "mordible".