it-swarm.com.de

Firefox "ssl_error_no_cypher_overlap" Fehler

Meine Kollegen und ich haben ein Problem mit Firefox 3.0.6, um auf eine Java 1.6.0 ___ 11-Webanwendung zuzugreifen, die wir entwickeln. Alles funktioniert überall von 1 bis 30 Minuten in der Sitzung ... aber irgendwann schlägt die Verbindung fehl und der folgende Fehler wird angezeigt:

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 funktioniert gut. Firefox löst den Fehler sowohl in Windows als auch in Fedora aus, sodass das Problem nicht an ein Betriebssystem gebunden zu sein scheint. Die Java EE-Anwendung wird auf einem Tomcat 6.0.16-Server ausgeführt. Alle Seiten werden mit TLS 1.0 über einen Apache 2.2.8-HTTP-Server mit mod_nss verschlüsselt.

Unser Apache-Server ist so konfiguriert, dass SSL 3.0-Verbindungen abgelehnt werden. Eine Hypothese, die wir haben, ist, dass Firefox möglicherweise versucht, eine SSL 3.0-Verbindung herzustellen ... aber warum?

Basierend auf etwas Googeln haben wir die folgenden Dinge versucht, aber ohne Erfolg:

  • verwendung von Firefox 2.x (einige Leute meldeten Fälle, in denen 2.x funktionierte, 3.x jedoch nicht):

  • aktivieren von SSL2

  • sSL3 deaktivieren

  • deaktivieren von OCSP (Tool> Optionen> Erweitert> Verschlüsselung> Validierung)

  • sicherstellen, dass der Virenschutz/die Firewall des Client-Computers Port 443 (https-Port) nicht blockiert oder überprüft

Irgendwelche Ideen?

17
Michael

Ich hatte das gleiche Problem, als ich das Zertifikat für unseren Server unter www.tpsynergy.com erneuerte. Nachdem wir das neue Serverzertifikat importiert und den Tomcat neu gestartet haben, war der Fehler ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Nach langem Suchen habe ich diesen Link https://www.sslshopper.com/certificate-key-matcher.html verwendet, um die CSR (Zertifikat-Signaturanforderung mit dem eigentlichen Zertifikat) zu vergleichen. Sie stimmten nicht überein. Also habe ich eine neue CSR erstellt, ein neues Zertifikat erhalten und dieses installiert. Es funktionierte.

Die gesamten Schritte für den Prozess sind also

  1. Erstellen Sie CSR auf demselben Server, auf dem das Zertifikat installiert wird

keytool -keysize 2048 -genkey -alias Tomcat -keyalg RSA -keystore tpsynergy.keystore (Ändern Sie den Domänennamen nach Bedarf)

Während der Erstellung werden Sie nach Vor- und Nachnamen gefragt. Geben Sie nicht Ihren Namen an, sondern verwenden Sie den Domänennamen. Zum Beispiel gab ich es als www.tpsynergy.com

2.keytool -certreq -keyalg RSA -Alias ​​Tomcat -Datei csr.csr -keystore tpsynergy.keystore

Dadurch wird eine csr.csr-Datei im selben Ordner erstellt. Kopieren Sie den Inhalt auf die Godaddy-Site und erstellen Sie das neue Zertifikat.

  1. Die heruntergeladene ZIP-Datei enthält drei Dateien Gd_bundle-g2-g1.crt Gdig2.crt Youractualcert.crt

  2. Sie müssen das Root-Zertifikat gdroot-g2.crt von Godaddy-Repository herunterladen.

  3. Kopieren Sie alle diese Dateien in dasselbe Verzeichnis, in dem Sie die CSR-Datei erstellt haben und in dem sich die Keystore-Datei befindet.

  4. Führen Sie nun die folgenden Befehle nacheinander aus, um die Zertifikate in den Keystore zu importieren

    keytool -import -trustcacerts -Alias-Wurzel -Datei Gd_bundle-g2-g1.crt -keystore tpsynergy.keystore

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

    keytool -import -trustcacerts -alias-intermediär -Datei gdig2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias Tomcat -DateiDomaindatei.crt -keystore tpsynergy.keystore

  5. Stellen Sie sicher, dass die Datei server.xml im Ordner conf diesen Eintrag enthält

     

  6. Starten Sie den Kater neu

In Anbetracht dessen, was Sie ausprobiert haben, und den Fehlermeldungen, würde ich sagen, dass dies mehr mit dem genauen verwendeten Algorithmus als mit der TLS/SSL-Version zu tun hatte. Verwenden Sie zufällig eine Nicht-Sun-JRE oder die Sicherheitsimplementierung eines anderen Anbieters? Versuchen Sie es mit einem anderen JRE/OS, um Ihren Server zu testen. Andernfalls können Sie möglicherweise nur sehen, was mit Wireshark (mit einem Filter von 'tcp.port == 443') los ist.

5
alexh

Wenn Sie den Vorgang der SSL-Aushandlung in Wikipedia überprüfen, werden Sie wissen, dass zu Beginn ClientHello und ServerHello Nachrichten zwischen dem Browser und dem Server gesendet werden.

Nur wenn die in ClientHello bereitgestellten Verschlüsselungen überlappende Elemente auf dem Server enthalten, enthält die ServerHello-Nachricht eine Verschlüsselung, die von beiden Seiten unterstützt wird. Andernfalls wird keine SSL-Verbindung hergestellt, da es keine gemeinsame Verschlüsselung gibt.

Um das Problem zu lösen, müssen Sie (normalerweise auf Betriebssystemebene) Verschlüsselungscodes installieren, anstatt den Browser intensiv zu testen (normalerweise hängt der Browser vom Betriebssystem ab). Ich bin mit Windows und IE vertraut, kenne mich aber mit Linux und Firefox aus, kann also nur auf die Fehler hinweisen, aber keine Lösung liefern.

3
Lex Li

Ich hatte ähnliche Probleme beim Durchsuchen von Websites (https: //) bei der Verwendung von Burp (oder zumindest ein Problem, das Sie zu dieser Seite führt, wenn Sie Google durchsuchen):

  • ssl_error_no_cypher_overlap in Firefox
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome

Es stellte sich heraus, dass es ein Problem mit mit Java 8 war. Als ich zu Java 7 wechselte, hörte das Problem auf.

1
SharpC

Als erstes würde ich die config für mod_nss überprüfen. Es ist das Seltsame, denn es ist deins, und es gibt keine, die es auf der Welt so mag :-) Wenn es einen großen Fehler in Firefox oder mod_nss selbst gab, hätten Sie das wahrscheinlich schon in Ihrem gefunden Google Quest. Die Tatsache, dass Sie mit der Konfiguration getüftelt haben (z. B. Deaktivieren von SSL3 und verschiedenen anderen zufälligen Anpassungen), ist ebenfalls verdächtig.

Ich würde zurück zu einer sehr Vanilla mod_nss config gehen und sehen, ob das funktioniert. Ändern Sie dann systematisch die aktuelle Konfiguration, bis Sie das Problem reproduzieren können. Durch den Klang ist die Fehlerquelle irgendwo in der Chiffre-Spec-Config von mod_nss und dem zugehörigen Protokoll-Aushandlungskram enthalten. Vielleicht haben Sie dort versehentlich etwas geändert, als Sie versuchen, SSLv3 zu deaktivieren (warum sollten Sie SSL3 deaktivieren? Normalerweise deaktivieren Sie V2?).

Eine andere Sache, die Sie überprüfen sollten, ist, dass Sie sich auf dem neuesten Stand von mod_nss befinden und es ist kein bekannter Fehler darin. Die Tatsache, dass es ihm gelingt, die Sitzung zu starten und später fehlzuschlagen, ist interessant - was darauf hindeutet, dass möglicherweise versucht wird, die Sitzung neu zu verhandeln und zu diesem Zeitpunkt keine Chiffren zu verhandeln. Es könnten also die symmetrischen Chiffren sein. Oder es könnte einfach ein Implementierungsfehler in Ihrer Version von mod_nss sein, der das Protokoll irgendwie stört.

Eine andere Idee, und das ist eine wilde Vermutung, ist, dass der Browser versucht, eine Sitzung fortzusetzen, die vor der Deaktivierung mit SSLv3 ausgehandelt wurde, und etwas bricht, wenn versucht wird, diese Sitzung fortzusetzen, wenn V3 deaktiviert ist, oder mod_nss vielleicht nicht nicht richtig umsetzen.

Der Java/Tomcat-Kram erscheint wie ein roter Hering, denn wenn ich Ihre Beschreibung nicht missverstanden habe, ist nichts davon am SSL-Handshake/Protokoll beteiligt. 

0
frankodwyer

Unter erweiterten Einstellungen von Firefox sollten Sie die Verschlüsselung einstellen können. Standardmäßig sollten SSL3.0 und TLS1.0 überprüft werden. Wenn firefox versucht, SSL-3.0-Verbindungen zu erstellen, deaktivieren Sie die Einstellung von SSL 3.0s.

wenn dies nicht funktioniert, suchen Sie in der about: config-Seite nach "ssl2" Mein Firefox hat Einstellungen, bei denen ssl2 standardmäßig auf "false" gesetzt ist ... 

0
nchris