Frage 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 problemlos:

  • 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)

Allerdings, wenn ich Client mit meinem Ubuntu 12.04 benutze (w / OpenSSL 1.0.1 14 Mar 2012) Ich bekomme einen Fehler:

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

Wie kann ich weitermachen?

Alle Tipps werden sehr geschätzt!


29
2018-05-15 10:46


Ursprung


Welches Protokoll und welche Verschlüsselung werden verwendet, wenn eine Verbindung von Windows hergestellt wird? - Shane Madden♦
Es sagt: 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 die höchste Priorität zu haben. Mit welcher Art von Server verbinden Sie sich? - Shane Madden♦
Vielleicht sind die Standardeinstellungen der neueren OpenSSL standardmäßig ältere SSL-Protokollversionen einzuschränken? Es würde einige Gründe geben, dies angesichts der jüngsten BEAST-Katastrophe zu tun ... - rackandboneman
D'oh, verstanden. Sie testen die Clients gegen Ihre Website. - brent


Antworten:


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

Es sieht nicht so aus, als wäre ein Fix verfügbar. Wenn möglich, könnten Sie auf 1.0.0 herunterstufen.

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


26
2018-05-17 15:11



Weitere Details zu dem Problem auf dem Debian-Ticket: bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452 - brent
P.S. Ich werde Ihnen das Kopfgeld geben, wenn es abläuft (19 Stunden) - Jaakko
Klingt gut :) Das letzte Stück Info, Upstream-Ticket mit OpenSSL, scheint die Ursache des Problems zu sein: rt.openssl.org/Ticket/... - brent
Vielen Dank! Diese Antwort funktioniert auch für OpenSSL 0.9.8zh 14 Jan 2016 auf Mac - tytk


Dieser Fehler kann durch eine ältere Version von openssl verursacht werden, wenn die Chiffre nicht erneut verhandelt werden kann (Ich habe ein selbstsigniertes Zertifikat mit elliptischen Kurven generiert).

Genauer gesagt, bekam ich den gleichen Fehler auf MacOS mit Standard-openssl-0.9.8zh

Nach der Installation der Brew-Version OpenSSL 1.0.2f ging der Fehler weg:

~/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

4
2018-06-08 19:57



nach einer brautinstallation war meine openssl-version in / usr / bin / openssl die alte version. Ich musste spezifisch zu /usr/local/Cellar/openssl/1.0.2o_2/bin gehen, um die späteste Version von openssl laufen zu lassen - Gopi Palamalai


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

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

wie von entdeckt Christoph W.


2
2018-06-19 08:57