SSL-Routinen: SSL23_WRITE: SSL-Handshake-Fehler

Ich versuche, mit OpenSSL eine Verbindung zu einem SSL-Server herzustellen.

Wenn ich renne:

openssl s_client -connect myhost.com:443

Die folgenden SSL-Client-Konfigurationen funktionieren einwandfrei:

Windows ( OpenSSL 0.9.83e 23 Feb 2007)
Linux ( OpenSSL 0.9.8o 01 Jun 2010)
Linux ( OpenSSL 1.0.0-fips 29 Mar 2010)

Die Ausgabe einer erfolgreichen Verbindung sieht folgendermaßen aus:

New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DES-CBC3-SHA
    Session-ID: (hidden)
    Session-ID-ctx:
    Master-Key: (hidden)
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1337266099
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Wenn ich jedoch einen Client mit meinem Ubuntu 12.04 (w / OpenSSL 1.0.1 14 Mar 2012) verwende, erhalte ich folgende Fehlermeldung:

CONNECTED(00000003)
...:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

Wie kann ich das lösen?

Alle Tipps werden sehr geschätzt!

ssl openssl

— Jaakko
quelle

Welches Protokoll und welche Verschlüsselung werden verwendet, wenn eine Verbindung über Windows hergestellt wird?

— Shane Madden

Dort heißt es: New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA. Ich wünschte, ich hätte verstanden, was das alles bedeutet! :)

— Jaakko

DES? Das ist eine seltsame Chiffre, um höchste Priorität zu haben. Mit welcher Art von Server verbinden Sie sich?

— Shane Madden

Vielleicht schränken die Standardeinstellungen des neueren OpenSL-Protokolls standardmäßig ältere SSL-Protokollversionen ein? In Anbetracht des jüngsten BEAST-Chaos würde es einige Gründe dafür geben ...

— rackandboneman

D'oh, verstanden. Sie testen die Clients anhand Ihrer Website.

— brent

Antworten:

Dies scheint ein bekanntes Problem mit Ubuntus 1.0.1 OpenSSL zu sein: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/965371

Es sieht nicht so aus, als ob ein Fix verfügbar wäre. Wenn möglich, können Sie ein Downgrade auf 1.0.0 durchführen.

Versuchen openssl s_client -tls1 -connect myhost.com:443

— brent
quelle

Weitere Details des Problems auf dem Debian-Ticket: bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452

— brent

PS Ich werde dir das Kopfgeld geben, wenn es abläuft (19 Stunden)

— Jaakko

Hört sich gut an :) Letzte Info, Upstream-Ticket mit OpenSSL, das die Hauptursache des Problems zu sein scheint: rt.openssl.org/Ticket/…

— brent

Vielen Dank! Diese Antwort funktioniert auch für OpenSSL 0.9.8zh am 14. Januar 2016 auf Mac

— tytk am

Dieser Fehler kann durch eine ältere Version von openssl verursacht werden, wenn die Verschlüsselung nicht erneut ausgehandelt werden kann (ich habe ein selbstsigniertes Zertifikat mit elliptischen Kurven generiert).

Insbesondere habe ich unter MacOS den gleichen Fehler mit der Standardeinstellung openssl - 0.9.8zh erhalten

Nach der Installation der Brew-Version OpenSSL 1.0.2f ist der Fehler behoben:

~/bin/openssl s_client -connect localhost:45678 | grep Cipher

verify return:1
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384

— Andrei Sura
quelle

Nach der Installation war meine OpenSL-Version in / usr / bin / openssl die alte Version. Ich musste speziell zu /usr/local/Cellar/openssl/1.0.2o_2/bin gehen, um die neueste Version von openssl

— Gopi Palamalai am

Wenn dieses Problem bei einem Java-HTTPS-Server auftritt, der unter OpenJDK ausgeführt wird, versuchen Sie /etc/java-7-openjdk/security/java.security, die Zeile zu bearbeiten und zu kommentieren

security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

wie von Christoph W entdeckt .

— Aldaviva
quelle