vsphere vcenter update for esxi java security apache firefox ssl

java - vcenter - Error "ssl_error_no_cypher_overlap" de Firefox



vmware host client ™ 1.8 0 ga (11)

Mis compañeros de trabajo y yo estamos teniendo un problema al utilizar Firefox 3.0.6 para acceder a una aplicación web Java 1.6.0 ___ 11 que estamos desarrollando. Todo funciona bien entre 1 y 30 minutos de la sesión ... pero, finalmente, la conexión falla y aparece el siguiente error:

Secure Connection Failed

An error occurred during a connection to 10.xxx

Cannot communicate securely with peer: no common encryption algorithm(s).

(Error code: ssl_error_no_cypher_overlap)

IE funciona bien. Firefox arroja el error tanto en Windows como en Fedora, por lo que el problema no parece estar vinculado a un sistema operativo. La aplicación Java EE se ejecuta en un servidor Tomcat 6.0.16. Todas las páginas están encriptadas usando TLS 1.0 a través de un servidor HTTP Apache 2.2.8 con mod_nss.

Nuestro servidor Apache está configurado para rechazar conexiones SSL 3.0. Una hipótesis que tenemos es que Firefox podría estar tratando de establecer una conexión SSL 3.0 ... ¿pero por qué?

Basado en Google, probamos las siguientes cosas, pero sin éxito:

  • utilizando Firefox 2.x (algunas personas informaron instancias en las que 2.x funcionó pero 3.x no):

  • habilitando SSL2

  • deshabilitando SSL3

  • deshabilitando OCSP (Herramienta> Opciones> Avanzado> Cifrado> Validación)

  • asegurando que el antivirus / firewall de la computadora cliente no esté bloqueando o escaneando el puerto 443 (puerto https)

¿Algunas ideas?


En la configuración avanzada de Firefox, deberías poder establecer el cifrado. De manera predeterminada, SSL3.0 y TLS1.0 deberían estar marcados, por lo que si firefox intenta crear conexiones de ssl 3.0, intente desmarcar la configuración de ssl 3.0s.

si eso no funciona, intente buscar en la página acerca de: config para "ssl2" Mi Firefox tiene configuraciones con ssl2 establecido en falso de manera predeterminada ...


Teniendo en cuenta lo que ha intentado y los mensajes de error, diría que esto tiene más que ver con el algoritmo de cifrado exacto utilizado en lugar de la versión TLS / SSL. ¿Está utilizando un JRE que no es de Sun por casualidad o la implementación de seguridad de un proveedor diferente? Pruebe con un JRE / OS diferente para probar su servidor si puede. De lo contrario, es posible que solo pueda ver lo que está sucediendo con Wireshark (con un filtro de ''tcp.port == 443'').


Lo primero que verificaría es la configuración para mod_nss. Es extraño, porque es tuyo y no hay ninguno en el mundo como este :-) Mientras que si había un gran error en Firefox o mod_nss en sí, supongo que ya habrías descubierto esto en tu búsqueda de google El hecho de que haya jugueteado con la configuración (por ejemplo, deshabilitar SSL3 y varios otros ajustes aleatorios), también es sospechoso.

Retrocedería a una configuración mod_nss muy vana y veré si eso funciona. Luego, cambie las cosas sistemáticamente hacia su configuración actual hasta que pueda reproducir el problema. Por su sonido, la fuente del error está en algún lugar de la configuración de especificación de cifrado de mod_nss y de las cosas relacionadas con la negociación del protocolo. Entonces, quizás cambiaste inadvertidamente algo al intentar desactivar SSLv3 (por cierto, ¿por qué desactivar SSL3? ¿Normalmente las personas deshabilitan V2?).

Otra cosa que debes comprobar es que estás en el último mod_nss y no es un error conocido en eso. El hecho de que se las arregle para iniciar la sesión y luego falla más tarde es interesante, sugiere que tal vez esté intentando renegociar la sesión y no poder negociar cifras en ese momento. Entonces podrían ser las cifras simétricas. O podría ser simplemente un error de implementación en su versión de mod_nss que de alguna manera deshabilita el protocolo.

Otra idea, y esta es una suposición descabellada, es que el navegador está intentando reanudar una sesión que se negoció con SSLv3 antes de que la desactivara, y algo se rompe al intentar reanudar esa sesión cuando V3 está apagado, o tal vez mod_nss simplemente doesn No lo implemente bien

Las cosas de java / tomcat parecen ser una pista falsa, ya que a menos que haya entendido mal tu descripción, nada de eso está involucrado en el protocolo de enlace SSL.


Si revisa el proceso de negociación SSL en Wikipedia, sabrá que al principio los mensajes ClientHello y ServerHello se envían entre el navegador y el servidor.

Solo si las cifras proporcionadas en ClientHello tienen elementos superpuestos en el servidor, el mensaje ServerHello contendrá una cifra que ambas partes admitirán. De lo contrario, la conexión SSL no se iniciará ya que no hay una cifra común.

Para resolver el problema, debe instalar las cifras (generalmente en el nivel del sistema operativo), en lugar de intentar con dureza en el navegador (generalmente el navegador se basa en el sistema operativo). Estoy familiarizado con Windows e IE, pero sé muy poco sobre Linux y Firefox, así que solo puedo señalar lo que está mal pero no puedo ofrecerle una solución.


He tenido el mismo problema; resolver fue suficiente para habilitar todos los esquemas SSL en "about: config". Los estaba encontrando filtrando con ssl. Primero analicé todas las opciones para desactivar las innecesarias.


Si obtiene el error de superposición sin cifrado en Firefox, y lo ha dejado en la configuración predeterminada, está utilizando lo que debe ser un sitio muy inseguro al tratar de usar un cifrado "de grado de exportación" muy débil. El uso de estos sistemas de cifrado está desaconsejado estos días y yo personalmente dejaría de usar un sitio que intenta utilizar un sistema de cifrado tan débil.


Mensaje de error "Código de error: ssl_error_no_cypher_overlap" después del inicio de sesión, cuando se esperaba la pantalla de bienvenida, utilizando el navegador Firefox

Solución

Habilite la compatibilidad con el cifrado RSA de 40 bits en el navegador Firefox: 1: ingrese ''about: config'' en la barra de direcciones del navegador 2: busque / seleccione "security.ssl3.rsa_rc4_40_md5" 3: configure boolean en TRUE


Mensaje de error "código de error: ssl_error_no_cypher_overlap" después del inicio de sesión, cuando se esperaba la pantalla de bienvenida - usando el navegador Firefox Solución 1: ingrese ''about: config'' en la barra de direcciones del navegador 2: busque / seleccione "security.ssl3.rsa_rc4_40_md5" 3: configure boolean CIERTO


Tuve el mismo problema al renovar el certificado de nuestro servidor en www.tpsynergy.com. Después de importar el nuevo certificado del servidor y reiniciar el tomcat, el error que recibíamos era ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Después de mucha investigación, utilicé este enlace https://www.sslshopper.com/certificate-key-matcher.html para comparar el csr (solicitud de firma de certificado con el certificado real). Ambos no coincidieron. Así que creé un nuevo csr y obtuve un nuevo certificado e instalé el mismo. Funcionó.

Entonces, los pasos completos para el proceso son

  1. Desde el mismo servidor donde se instalará el certificado, crea CSR

keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tpsynergy.keystore (cambie el nombre de dominio según sea necesario)

Al crear esto, pedirá el nombre y apellido. No dé su nombre, pero use el nombre de dominio. Por ejemplo, lo di como www.tpsynergy.com

2.keytool -certreq -keyalg RSA -alias tomcat -file csr.csr -keystore tpsynergy.keystore

Esto creará un archivo csr.csr en la misma carpeta. copie el contenido de esto al sitio godaddy y cree el nuevo certificado.

  1. El archivo zip del certificado descargado tendrá tres archivos gd_bundle-g2-g1.crt gdig2.crt youractualcert.crt

  2. Deberá descargar la raíz cert gdroot-g2.crt del repositorio godaddy.

  3. Copie todos estos archivos en el mismo directorio desde el que creó el archivo CSR y donde se encuentra el archivo del almacén de claves.

  4. Ahora ejecute los comandos siguientes uno por uno para importar los certificados en el almacén de claves

    keytool -import -trustcacerts -alias root -file gd_bundle-g2-g1.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias root2 -file gdroot-g2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias intermedio -file gdig2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias tomcat -archivo yourdomainfile.crt -keystore tpsynergy.keystore

  5. Asegúrese de que el archivo server.xml en la carpeta conf tenga esta entrada

  6. Reiniciar el tomcat


Lo que funcionó para mí es I:

  1. Fuimos a about: config.
  2. Mecanografió "seguridad" en el cuadro de búsqueda.
  3. Establezca todas las entradas devueltas a sus valores predeterminados.
  4. Escriba "ssl" en el cuadro de búsqueda.
  5. Establezca todos los resultados devueltos a sus valores predeterminados.
  6. Habilitado ssl2.
  7. Disabled ssl3.
  8. Reinició Firefox.

Nota sobre el reinicio de Firefox: cuando lo inicio muy pronto después de cerrarlo, a menudo tiene un problema de acceso a los archivos, que me obliga a eliminar places.sqlite y places.sqlite-journal en C: / WINDOWS / Application Data / Mozilla / Firefox / Profiles / n18091xv.default . Esto hace que pierda mi historial, además de que los marcadores deben restaurarse a partir de una copia de seguridad cada vez que esto sucede. Espero de cinco a diez minutos o más para evitar esta molestia.

Ejecutando Firefox v3.5.1 en WinMe


Tuve problemas similares navegando a sitios seguros (https: //) cuando usé Burp (o al menos un problema que lo llevaría a esta página cuando busco en Google):

  • ssl_error_no_cypher_overlap en Firefox
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH en Chrome

Resultó ser un problema con el uso de Java 8 . Cuando cambié a Java 7, el problema se detuvo.