httpUtils will bei einem Modul sslv3 - Bug, meine Dummheit oder was?

[rudolfkoenig]

SSLv23 erlaubt SSLv2 und SSLv3, obwohl Du es direkt danach verbietest - so verstehe ich das jedenfalls.

Laut "perldoc IO::Socket:SSL" (ausgfuehrt in einem Terminalfenster) erlaubt die aktuelle Voreinstellung TLS 1.0, 1.1 und 1.2.

The default SSL_version is 'SSLv23:!SSLv2' which means, that
             SSLv2, SSLv3 and TLSv1 are supported for initial protocol
             handshakes, but SSLv2 will not be accepted, leaving only SSLv3
             and TLSv1. You can also use !TLSv1_1 and !TLSv1_2 to disable TLS
             versions 1.1 and 1.2 while allowing TLS version 1.0.

             Setting the version instead to 'TLSv1' will probably break
             interaction with lots of clients which start with SSLv2 and then
             upgrade to TLSv1. On the other side some clients just close the
             connection when they receive a TLS version 1.1 request. In this
             case setting the version to 'SSLv23:!SSLv2:!TLSv1_1:!TLSv1_2'
             might help.

Rudolf, bitte nicht "lies mal das und das". Sage mir bitte einfach "Gib mal 'cat trullala' ein" - eine Handreichung dieser Art bitte. Danke.

Habe ich doch

[CoolTux]

Nein.

Ganz anders herum:
Zeige mir EINE solche Kommunikation, die ausschließlich (!) noch via SSL 2/3 bedient. Die also nicht antwortet, wenn clientseitig TLS erlaubt ist.

Es ist unvorstellbar, dass ein öffentlich verfügbarer Server *kein* TLS anbietet.

Du wärst erstaunt und entsetzt zu gleich.
Aber davon mal ab, auch innerhalb der privaten Gefilde wird mittlerweile SSL verwendet. Heizungssystem, lokale API von Google Home, Bestimmte Lichtprodukte und auch z.B. meine Klimaanlage. Alle haben aber ein alter und sind von Chinaexperten entwickelt worden welche halt kein TLS verwenden. Ich behaupte das wir mehr lokale Systeme mit HttpUtils abfragen wie öffentliche.

Am Ende hat ja jeder die Möglichkeit über das global Device ssl zu ändern. Aktuell bringt nur warnung.bund.de und vielleicht 2 weitere Seiten diese Probleme. Und ich denke nicht mal das es an FHEM liegt sondern entweder an der Perl SSL Implementierung oder an der openssl Bibliothek. Ich gehe eher in Richtung openssl.
Man müsste sich wie gesagt die Verhandlungen über das Protokoll einmal anschauen.

Der Client baut die Verbindung auf, der Server sagt dem Client was er zu lässt (steht im Zertifikat )und dann verbindet sich der Client mit dem entsprechenden erlaubten Optionen durch Testverbindungen. Klappen diese wird die eigentliche Verbindung aufgebaut. So viel zur Theorie.


Grüße

[curt]

The default SSL_version is 'SSLv23:!SSLv2' which means, that
             SSLv2, SSLv3 and TLSv1 are supported for initial protocol
             handshakes, but SSLv2 will not be accepted

Ich glaube, wir sind nahe dran.

Da oben steht, dass ssl2 und ssl3 Protokolle aushandeln dürfen, aber danach ssl2 nicht reden darf.

Übersetzt in Dein/unser Konstrukt "SSLv23:!SSLv3:!SSLv2" bedeutet das, dass ssl2/3 fröhlich mit den Zielserver vor sich hinverhandeln darf, danach aber ssl2/3 als Ebene verboten ist. Soweit erstmal klar.

Bislang ging das immer gut: Die Verhandlungsebene SSLv23 bekam Hinweis "Du bekommst TLS, das geht."

Das geht neuerdings schief. Siehe oben.

Wenn ich nun (schon praktisch bewiesen) in meiner Interpretation der Sache die Verhandlungsebene (der Verbindung) SSLv23 durch !SSLv23 ausschalte, dann funktioniert alles.

[curt]

Du wärst erstaunt und entsetzt zu gleich.

Es geht ja um Zielserver (gern im Intranet) die kein TLS können. Magst Du mir bitte eins zeigen?

[krikan]

Code Auswählen Erweitern

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES128-GCM-SHA256

Laut Internetrecherche:
Chiper AES128-GCM-SHA256 wurde erst mit TLSv1.3 eingeführt (https://tools.ietf.org/html/rfc8446). Vorgabe einer Übertragung auf TLSv1.2 finde ich nicht, darum verstehe ich die Kombination von Protocol und Cipher nicht.

TLSv1.3 setzt mindestens OpenSSL 1.1.1 voraus. (https://wiki.openssl.org/index.php/TLS1.3)

[rudolfkoenig]

Will nochmal festhalten, dass das Problem nur auf bestimmten Clients auftritt, da ich mit

Code Auswählen Erweitern

fhem> { GetFileFromURL("https://warnung.bund.de/bbk.dwd/unwetter.json") }
[]kein Problem habe.

Weiterhin hilft vlt. auf unserem Verstandnisweg die Ausgabe von "perl analyze-ssl.pl warnung.bund.de":

...
* maximum SSL version  : TLSv1_2 (SSLv23)
* supported SSL versions with handshake used and preferred cipher(s):
   * handshake protocols ciphers
   * SSLv23    TLSv1_2   AES128-GCM-SHA256
   * TLSv1_2   TLSv1_2   AES128-GCM-SHA256
   * TLSv1_1   FAILED: SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
   * TLSv1     FAILED: SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* cipher order by      : server
...

Laut diesen Daten waere SSLv23 nicht eine Zusammenfassung von SSLv2, SSLv3 und TLSv1 (wie ich das Anhand von perldoc IO::Socket::SSL angenommen habe), sondern eine eigenstaendige Version.

Wenn AES128-GCM-SHA256 in der Problemfall-Bibliothek mit TLSv1.2 zugelassen ist, aber mit SSLv23 nicht, dann erklaert das, warum sslVersion="TLSv12" oder "!SSLv23:!SSLv3:!SSLv2" funktioniert. Ich wuerde das aber als ein Bug (vmtl. beim Server, sicher ist das erst nach Studium aller RFCs) einstufen, und deswegen keine Defaults in FHEM umstellen.

[CoolTux]

Danke Dir Christian für Deine gute Recherche. Es wäre also zu mindest ein Grund für die Probleme.
Ich würde da heute Abend noch mal schauen, oder eventuell mag ein anderer das kurz verifizieren.

Ich glaube Mozilla hat da auch eine Seite wo man so Sachen noch testen kann
Allerdings verstehe ich nicht wie man dann den Cipher in Verbindung mit v1.2 auswählen kann.


Grüße

[CoolTux]

Laut curl Seite
TLS v1.2 cipher suites
NULL-SHA256 AES128-SHA256 AES256-SHA256 AES128-GCM-SHA256 AES256-GCM-SHA384


Da ich aktuell unterwegs bin. Kann das bitte einmal jemand auf seinem System checken?

Code Auswählen Erweitern

openssl ciphers -v | grep TLSv1.2

[mahowi]

Laut curl Seite
TLS v1.2 cipher suites
NULL-SHA256 AES128-SHA256 AES256-SHA256 AES128-GCM-SHA256 AES256-GCM-SHA384


Da ich aktuell unterwegs bin. Kann das bitte einmal jemand auf seinem System checken?

Code Auswählen Erweitern

openssl ciphers -v | grep TLSv1.2

Code Auswählen Erweitern

dietpi@fhem:~$ openssl ciphers -v | grep TLSv1.2
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

Code Auswählen Erweitern

dietpi@fhem:~$ openssl version
OpenSSL 1.1.1c  28 May 2019

[CoolTux]

Code Auswählen Erweitern

AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

Sollte also laut openssl funktionieren.

[frank]

Code Auswählen Erweitern

AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

Sollte also laut openssl funktionieren.

nicht eher deswegen?

Code Auswählen Erweitern

AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD

[CoolTux]

nicht eher deswegen?

Code Auswählen Erweitern

AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD

Doch hast Recht. Genau deswegen. Danke Dir

[curt]

@mahowi
Bei mir identisch.

Es ist ja schön, dass es funktionieren *sollte* - aber es funktioniert halt nicht.

Und so eng finde ich das Cyper-Suite-Modell des Zielservers gar nicht: Bitte mal https://www.ssllabs.com/ssltest/ aufrufen.

Auf meinem System getestet:

Code Auswählen Erweitern


# openssl s_client -connect warnung.bund.de:443
CONNECTED(00000003)
1996079120:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1536:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 307 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)


Also kein Problem von FHEM direkt - nur hilft diese Erkenntnis erstmal wenig.

[CoolTux]

Und welche openssl Version hast Du? Welches System (Distrie)?

[curt]

Raspian 10 buster (upgrade von 9).
OpenSSL 1.1.1c  28 May 2019

Ich bin der Threadopener.
Neben @mahowi , den das auch betrifft, bin ich die Zielgruppe des Problems.

P.S: Siehe auch https://blog.pki.dfn.de/2014/10/ssl-3-0-abschalten/