web-dev-qa-db-fra.com

Erreur Firefox "ssl_error_no_cypher_overlap"

Mes collègues et moi-même rencontrons des difficultés lors de l'utilisation de Firefox 3.0.6 pour accéder à une application Web Java 1.6.0 ___ 11 en cours de développement. Tout fonctionne bien entre 1 et 30 minutes dans la session ... mais finalement, la connexion échoue et l'erreur suivante apparaît:

Secure Connection Failed

An error occurred during a connection to 10.x.x.x.

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

(Error code: ssl_error_no_cypher_overlap)

IE fonctionne bien. Firefox renvoie l'erreur dans Windows et Fedora. Le problème ne semble donc pas lié à un système d'exploitation. L'application Java EE s'exécute sur un serveur Tomcat 6.0.16. Toutes les pages sont chiffrées à l'aide de TLS 1.0 via un serveur HTTP Apache 2.2.8 avec mod_nss.

Notre serveur Apache est configuré pour rejeter les connexions SSL 3.0. Une hypothèse que nous avons est que Firefox pourrait essayer d'établir une connexion SSL 3.0 ... mais pourquoi?

À partir de Google, nous avons essayé les solutions suivantes, mais sans succès:

  • en utilisant Firefox 2.x (certaines personnes ont signalé des cas où 2.x fonctionnait mais que 3.x ne fonctionnait pas):

  • activer SSL2

  • désactiver SSL3

  • désactiver OCSP (Outil> Options> Avancé> Cryptage> Validation)

  • vérifier que l'antivirus/pare-feu de l'ordinateur client ne bloque pas ou n'analyse pas le port 443 (port https)

Des idées?

javasecurityapachefirefoxssl
17
Michael

J'ai eu le même problème lors du renouvellement du certificat pour notre serveur à l'adresse www.tpsynergy.com. Après l'importation du nouveau certificat de serveur et le redémarrage de Tomcat, ERRE_SSL_VERSION_OR_CIPHER_MISMATCH était l'erreur que nous obtenions. Après de nombreuses recherches, j'ai utilisé ce lien https://www.sslshopper.com/certificate-key-matcher.html pour comparer le csr (demande de signature de certificat au certificat réel). Ils ne correspondaient pas tous les deux. J'ai donc créé un nouveau csr, obtenu un nouveau certificat et installé le même. Ça a marché.

Donc, toutes les étapes du processus sont

  1. À partir du même serveur sur lequel le certificat sera installé, créez CSR.

keytool -keysize 2048 -genkey -alias Tomcat -keyalg RSA -keystore tpsynergy.keystore (modifiez le nom de domaine si nécessaire)

Lors de la création, il vous demandera le prénom et le nom de famille. Ne donnez pas votre nom, mais utilisez le nom de domaine. Par exemple je l'ai donné comme www.tpsynergy.com

2.keytool -certreq -keyalg RSA -alias Tomcat -fichier csr.csr -keystore tpsynergy.keystore

Cela créera un fichier csr.csr dans le même dossier. copiez le contenu de celui-ci sur le site GoDaddy et créez le nouveau certificat.

  1. Le fichier Zip de certificat téléchargé aura trois fichiers Gd_bundle-g2-g1.crt Gdig2.crt Youractualcert.crt

  2. Vous devrez télécharger le certificat racine gdroot-g2.crt à partir du référentiel de godaddy.

  3. Copiez tous ces fichiers dans le même répertoire à partir duquel vous avez créé le fichier CSR et où se trouve le fichier de magasin de clés.

  4. Maintenant, exécutez les commandes ci-dessous une à une pour importer les certificats dans le magasin de clés.

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

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

    keytool -import -trustcacerts -alias intermédiaire -fichier gdig2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias Tomcat -fichier yourdomainfile.crt -keystore tpsynergy.keystore

  5. Assurez-vous que cette entrée figure dans le fichier server.xml du dossier conf.

     

  6. Redémarrez le Tomcat

7
Srinivasan Rajagopalan

Compte tenu de ce que vous avez essayé et des messages d'erreur, je dirais que cela était davantage lié à l'algorithme de chiffrement exact utilisé qu'à la version TLS/SSL. Utilisez-vous par hasard un environnement JRE autre que Sun ou une implémentation de la sécurité d'un autre fournisseur? Essayez un autre JRE/OS pour tester votre serveur si vous le pouvez. Sinon, vous pourrez peut-être voir ce qui se passe avec Wireshark (avec un filtre de 'tcp.port == 443').

5
alexh

Si vous passez en revue le processus de négociation SSL sur Wikipedia, vous saurez qu'au début, les messages ClientHello et ServerHello sont envoyés entre le navigateur et le serveur.

Ce n'est que si les éléments fournis dans ClientHello se chevauchent sur le serveur que le message ServerHello contient un chiffrement pris en charge par les deux côtés. Sinon, la connexion SSL ne sera pas lancée car il n'y a pas de chiffrement commun.

Pour résoudre le problème, vous devez installer cyphers (généralement au niveau du système d'exploitation), au lieu d'essayer sérieusement le navigateur (le navigateur repose généralement sur le système d'exploitation). Je connais bien Windows et IE, mais je connais peu Linux et Firefox. Je ne peux donc que vous indiquer ce qui ne va pas, mais je ne peux pas vous proposer de solution.

3
Lex Li

J'ai eu des problèmes similaires lors de la navigation sur des sites sécurisés (https: //) lors de l'utilisation de Burp (ou au moins un problème susceptible de vous amener à cette page lors de la recherche sur Google):

  • ssl_error_no_cypher_overlap dans Firefox
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH dans Chrome

Cela s'est avéré être un problème avec en utilisant Java 8 . Lorsque je suis passé à Java 7, le problème s'est arrêté.

1
SharpC

La première chose que je voudrais vérifier est la configuration pour mod_nss. C'est l'intrus, car c'est le vôtre et il n'y en a aucun dans le monde comme celui-ci :-) Alors que s'il y avait un énorme bug dans Firefox ou dans le mod_nss lui-même, je suppose que vous l'auriez déjà découvert dans votre google quête. Le fait que vous ayez manipulé la configuration (par exemple, en désactivant SSL3 et divers autres réglages aléatoires) est également suspect.

Je reviens sur une configuration très vanille mod_nss et je vois si ça marche. Puis changez systématiquement les choses vers votre configuration actuelle jusqu'à ce que vous puissiez reproduire le problème. Par le son de celle-ci, la source de l'erreur se situe quelque part dans la configuration de spécification de chiffrement de mod_nss et dans le processus de négociation de protocole associé. Alors peut-être avez-vous par inadvertance modifié quelque chose lorsque vous avez essayé de désactiver SSLv3 (pourquoi, de fait, désactiver SSL3? Normalement, les utilisateurs désactivent la version 2?).

Une autre chose à vérifier est que vous êtes sur le dernier mod_nss et que ce n’est pas un bogue connu dans ce domaine. Le fait qu'il réussisse à démarrer la session puis échoue plus tard est intéressant - cela suggère qu'il est peut-être en train de renégocier la session et de ne pas négocier les chiffrements à ce stade. Cela pourrait donc être les chiffres symétriques. Ou il pourrait simplement s'agir d'un bogue d'implémentation dans votre version de mod_nss qui perturbe en quelque sorte le protocole.

Une autre idée, et il s’agit d’une hypothèse improbable, est que le navigateur essaie de reprendre une session négociée avec SSLv3 avant de la désactiver, et que quelque chose se brise lorsqu’on tente de reprendre cette session lorsque la V3 est désactivée, ou mod_nss pas le mettre en œuvre correctement.

Le langage Java/Tomcat semble être un fouillis rouge, car à moins que je ne comprenne mal votre description, rien de tout cela n’est impliqué dans le protocole/protocole de liaison SSL. 

0
frankodwyer

Sous les paramètres avancés de Firefox, vous devriez pouvoir définir le cryptage. Par défaut, SSL3.0 et TLS1.0 doivent être cochés. Par conséquent, si Firefox tente de créer des connexions SSL 3.0, décochez la case correspondante.

si cela ne fonctionne pas, essayez de rechercher "ssl2" dans la page about: config. 

0
nchris