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

[curt]

@rudolfkoenig

Bei genau einem Modul wird bei mir (und offenbar nur bei mir) ssl3 aufgerufen. Das geht schief, der Zielserver lehnt ab. Verständlich.

2019-07-19_20:59:50 Nina lastConnection: https://warnung.bund.de/bbk.dwd/unwetter.json: Can't connect(2) to https://warnung.bund.de:443:  SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Es geht um das im Alpha-Stadium befindliche Modul 77_Nina.pm von @KölnSolar - hier zu finden: https://forum.fhem.de/index.php/topic,102346.0.html

Möglicherweise hilfreich ist die Erklärung, dass ich kurz vor Erscheinen des Moduls von Raspian-9 auf Raspian-10 buster updatete, keine Neuinstallation, sondern Update. Weiterhin hilfreich könnte die Beobachtung sein, dass bei keinem anderen von mir genutzten Modul. welches httpUtils einsetzt, dieses Verhalten auftritt.

Ich habe als workaround im Modul sslargs => { SSL_version => 'TLSv12' }, ergänzt, damit läuft das Modul bei mir. Eine langfristige Lösung kann das aber nicht sein.

Rudolf, kannst Du Dir das bitte mal ansehen? Bzw. hast Du Hinweise für mich?

[rudolfkoenig]

Vorneweg: ich bin kein SSL Experte, weiterhin sind die OpenSSL Fehlermeldungen mAn schlecht und/oder unverstaendlich.

Die Voreinstellung fuer SSL_version in HttpUtils ist SSLv23:!SSLv3:!SSLv2, was, wenn ich meine Version der Doku richtig verstehe, TLSv1_1 und TLSv1_2 erlaubt, SSLv3 und SSLv2 nicht, und fuer die meisten FHEM-Benutzer keine Probleme verursacht. Mag sein, das in deiner Version der OpenSSL Bibliothek diese Voreinstellung was anderes bewirkt (z.Bsp. kein TLSv1_2).

Ich wil eigentlich die Voreinstellung denen ueberlassen, die sich damit auskennen, deswegen habe ich aus TCPServerUtils die SSL_version Voreinstellung entfernt. Vmtl. ist Zeit das auch in HttpUtils zu entfernen, damit gilt auch hier die Voreinstellung der verwendeten Bibliothek. Kannst du das bitte testen, und Feedback geben?

Diese Voreinstellung kann man mit der globalen Attribut sslVersion, oder wenn das Modul es anbietet (wie HTTPMOD),  auch mit dem Modul eigenen sslVersion Attribut ueberschreiben. Vmtl. sollte dieses Attribut auch in 77_Nina.pm eingebaut werden.

[Hollo]

@rudolfkoenig

Bei genau einem Modul wird bei mir (und offenbar nur bei mir) ssl3 aufgerufen...

Zur Be(un)ruhigung kann ich sagen, dass ich die identische Fehlermeldung erhielt.

[curt]

Vorneweg: ich bin kein SSL Experte, weiterhin sind die OpenSSL Fehlermeldungen mAn schlecht und/oder unverstaendlich.

Schlechte Voraussetzungen - ich auch nicht. Grober Überblick - ja. Die Verästelungen ... hmm. Wer aus dem Forum käme denn in Frage?

Die Voreinstellung fuer SSL_version in HttpUtils ist SSLv23:!SSLv3:!SSLv2, was, wenn ich meine Version der Doku richtig verstehe, TLSv1_1 und TLSv1_2 erlaubt, SSLv3 und SSLv2 nicht, und fuer die meisten FHEM-Benutzer keine Probleme verursacht. Mag sein, das in deiner Version der OpenSSL Bibliothek diese Voreinstellung was anderes bewirkt (z.Bsp. kein TLSv1_2).

Ich befürchte ja, dass der Wurm irgendwo bei FHEM oder einem Modul (ggf HttpUtils) ist. Denn die Sache ist anders: Es gibt https://www.ssllabs.com/ssltest/ - damit kann man gut testen, was der Zielserver eigentlich versteht und akzeptiert. Zielserver des Moduls ist warnung.bund.de und wir lernen, dass der ausschließlich TLS 1.2 (also TLSv1_2) akzeptiert und da auch nur bestimmte Cipher Suites.

Und nun der Wurm: Mit den Voreinstellungen von HttpUtils und 77_Nina (hat keine!) müsste es also problemlos gehen. Aber unsere Seite fällt auf SSLv3 zurück - was aber eigentlich auf unserer Seite verboten ist - er aber trotzdem macht. Aus meiner Sicht ist das ein schwerer Fehler, quasi der zweite schon.

Wenn ich wie gesagt im Modul 77_Nina ihm ZUSÄTZLICH sslargs => { SSL_version => 'TLSv12' } auf den Weg gebe, dann geht es. Weiß der Geier warum.
TLSv12:TLSv11:!SSLv3:!SSLv2 geht wiederum nicht. Warum auch immer.

Ich wil eigentlich die Voreinstellung denen ueberlassen, die sich damit auskennen, deswegen habe ich aus TCPServerUtils die SSL_version Voreinstellung entfernt. Vmtl. ist Zeit das auch in HttpUtils zu entfernen, damit gilt auch hier die Voreinstellung der verwendeten Bibliothek. Kannst du das bitte testen, und Feedback geben?

Ich habe dort

Code Auswählen Erweitern

$par{SSL_version}  = $sslVersion if(!$par{SSL_version});
auskommentiert. War das gemeint?

Geändertes Modul gemeinsam mit originalem 77_Nina getestet - geht nicht. Da will er wieder sslv3 und wird von der Gegenseite erwartungsgemäß abgeblockt.

Diese Voreinstellung kann man mit der globalen Attribut sslVersion, oder wenn das Modul es anbietet (wie HTTPMOD),  auch mit dem Modul eigenen sslVersion Attribut ueberschreiben. Vmtl. sollte dieses Attribut auch in 77_Nina.pm eingebaut werden.

Damit ist das gemeint, was ich experimentell 77_Nina schon mit auf den Weg gab? Oder noch was anderes?

@Hollo
Wo genau? Auch bei 77_Nina? Oder woanders?
Kannst Du mithelfen?

[curt]

@rudolfkoenig

In der Zwischenzeit habe ich viel gelesen, recherchiert, in FHEM getestet. Ich habe mir ein Urteil gebildet welches ich hier zur Diskussion stelle.

* Es geht um HttpUtils und insbesondere die SSL-Kommunikation zu entfernten Dienstleistern, die im Web bzw. im Intranet Informationen anbieten. Dabei geht es einerseits um direkte Nutzung von HttpUtils via Device HTTPMOD, andererseits um indirekte Nutzung durch viele Module.

* Seit spätestens 2015 sind SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 unsicher. Sie sollen (und müssen) abgeschaltet werden, übrig bleibt nur TLS 1.2. - Das betrifft zunächst die Server, also die Zielserver, die wir abfragen, in FHEM deren Ergebnisse nutzen: Man kann davon ausgehen, dass große Anbieter (und im Grunde nutzen wir nur die) das in den letzten vier Jahren insoweit umsetzten, dass *alle* TLS 1.2 anbieten. Man muss sogar davon ausgehen, dass Server wie in der Hierarchie bund.de ausschließlich TLS 1.2 anbieten (wie bereits jetzt warnung.bund.de .

* Die Sicherheitseinstellungen (und damit das komplette Modell) müssen vom Kopf auf die Füße gestellt werden:
** HttpUtils muss alles abschalten, was im ersten Anstrich verboten ist. Das bedeutet dort:

Code Auswählen Erweitern


# my $sslVersion = AttrVal("global", "sslVersion", "SSLv23:!SSLv3:!SSLv2");
my $sslVersion = AttrVal("global", "sslVersion", "!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2");

[¹]

** HttpUtils muss für den Notfall ein Überschreiben durch Module (und HTTPMOD, da über attr) zulassen. Anders gesagt: Künftig ist das Rollenmodell geändert: Es ist nicht mehr (fast) alles erlaubt und muss verboten werden - sondern es ist (fast) alles verboten und muss im Einzelfall erlaubt werden. [²]

Ich habe
1) 77_Nina in den Originalzustand versetzt
2) HttpUtils entsprechend [¹] geändert.
Ich sehe bei mir keinerlei Auffälligkeiten. Ich bitte andere darum, das bei sich auch zu testen.

Aus meiner Sicht führt um die Änderung [¹] kein Weg vorbei: Früher oder später wird es hier oder da wieder knallen. Dann wird an Modulen gefrickelt werden - es muss aber systemisch an der Wurzel sein: Umstellung von "erlaubt bis von einem Modul verboten" auf "verboten bis von einem Modul erlaubt".

[¹] Die Idee, dabei gleich "TLSv1_3" mit freizuschalten funktioniert nicht: fhem.pl stürzt (bei mir) während des Starts ab.

[²] Der Fall trat bereits 2015 innerhalb FHEM auf, wurde aber übersehen und führte zum falschen Lösungsansatz, siehe https://forum.fhem.de/index.php?topic=33819.0 - Dort im Thread war die richtige Lösung aber im Grunde schon beschrieben.

[KölnSolar]

wenn ich Rudi richtig verstanden hab, dann müsstest Du mal probieren, ob attr global sslVersion das Problem bei Dir löst(bzw. dann andere Probleme erzeugt)

Vmtl. sollte dieses Attribut auch in 77_Nina.pm eingebaut werden.

halte ich auch für den falschen Weg.

Dann wird an Modulen gefrickelt werden - es muss aber systemisch an der Wurzel sein

So sehe ich das auch.

Ich könnt natürlich

Code Auswählen Erweitern

im Modul sslargs => { SSL_version => 'TLSv12' }einbauen.
Zu Nebenwirkungen fragen Sie bitte Ihren Arzt oder Apotheker.   

[rudolfkoenig]

In der Zwischenzeit habe ich viel gelesen, recherchiert, in FHEM getestet.

Und damit haette FHEM seinen ersten SSL-Experten

Ich habe dort [...] auskommentiert. War das gemeint?

Nein, damit hast du nur die Moeglichkeit, in einem Modul sslVersion zu setzen, entfernt.

Ich meinte Folgendes:

Code Auswählen Erweitern

--- FHEM/HttpUtils.pm    (revision 19853)
+++ FHEM/HttpUtils.pm    (working copy)
@@ -487,7 +487,7 @@
         }
       }

-      my $sslVersion = AttrVal("global", "sslVersion", "SSLv23:!SSLv3:!SSLv2");
+      my $sslVersion = AttrVal("global", "sslVersion", undef);
       $sslVersion = AttrVal($hash->{NAME}, "sslVersion", $sslVersion)
         if($hash->{NAME});
       my %par = %{$hash->{sslargs}};


my $sslVersion = AttrVal("global", "sslVersion", "!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2");

Laut Internet wurde TLS 1.2 2008 spezifiziert, OpenSSL hat es 2012 mit Version 1.0.? implementiert, IO::Socket::SSL noch spaeter uebernommen: ich gehe davon aus, dass wir Probleme mit aelteren FHEM-Installationen kriegen, wenn wir das so belegen.
Ich praeferiere weiterhin die gerade gezeigte Version, ohne eine FHEM-Seitige Voreinstellung.
Damit muss ich es auch nicht anpassen, wenn 1.2 angreifbar wird, und 1.4 die einzig sichere Einstellung ist.
Wer paranoid ist / der Bibliothek nicht traut / es besser weiss, der darf ja "attr global sslVersion" setzen.

> Vmtl. sollte dieses Attribut auch in 77_Nina.pm eingebaut werden.
halte ich auch für den falschen Weg.

Fuer den Normalfall sollte man kein Attribut setzen muessen.
Es geht mir darum, dass in einem Spezialfall der Benutzer die Moeglichkeit hat, lokal fuer eine Nina/HTTPMOD/etc Instanz eine andere Einstellung zu waehlen.

[KyleK]

@curt
Ich hab genau das gleiche Problem, seit ich Rasbian "Buster" auf meinem Raspberry Pi 3B+ installiert habe.

Ich vermute stark, dass es ein "Problem" mit dem installierten OpenSSL ist (OpenSSL/1.1.1c), denn das bei der Distro mitgelieferte curl ist ebenfalls nicht in der Lage, die JSON von warnung.bund.de herunterzuladen.

wget dagegen funktioniert ohne Probleme.

[curt]

@KölnSolar

wenn ich Rudi richtig verstanden hab, dann müsstest Du mal probieren, ob attr global sslVersion das Problem bei Dir löst(bzw. dann andere Probleme erzeugt)

Auch der falsche Ansatz, zumindest langfristig. Das würde bedeuten, dass nach und nach jeder das bei sich reinfrickelt. Denn man muss davon ausgehen, dass
1) nach und nach immer mehr auf buster updaten (Debian/Raspian)
2) Andere Distributionen das auch nicht anders halten
3) Weitere WebServer liefern nur noch TLS 1.2 aus

Ich könnt natürlich

Code Auswählen Erweitern

im Modul sslargs => { SSL_version => 'TLSv12' }einbauen.
Zu Nebenwirkungen fragen Sie bitte Ihren Arzt oder Apotheker.   

Bezogen auf Dein Modul (!) wäre das ein Weg. Und wenn Rudolf im Moment sagt "das lassen wir so" - wäre das der einzige Weg. Nebenwirkungen kann es keine geben: warnung.bund.de liefert nurTLS 1.2. Dein Modul gibt TLS 1.2 vor. Passt.

[curt]

@KyleK

Ich hab genau das gleiche Problem, seit ich Rasbian "Buster" auf meinem Raspberry Pi 3B+ installiert habe.

Die beiden möglichen workarounds (beide oben) hast Du erfasst? Oder soll ich nochmal genau erklären? (Beide haben den Nachteil, dass beim nächsten Update alles weg ist ...)

[curt]

In der Zwischenzeit habe ich viel gelesen, recherchiert, in FHEM getestet.

Und damit haette FHEM seinen ersten SSL-Experten

Das vergessen wir mal ganz schnell wieder. Ich komme aus der Branche - da lernt man als erstes: Nie sich selbst überschätzen.

Meine Hoffnung war eher: Es steigen noch weitere in die Diskussion ein, es wird hier doch locker eine handvoll User geben, die sich mit SSL gut auskennen. Leider noch niemand gekommen.

-      my $sslVersion = AttrVal("global", "sslVersion", "SSLv23:!SSLv3:!SSLv2");
+      my $sslVersion = AttrVal("global", "sslVersion", undef);

Danke für den Hinweis. Nein, das ändert das Verhalten nicht: Er fällt auf ssl3 zurück - und scheitert an warnung.bund.de - welcher ja nur TLS 1.2 anbietet.

Laut Internet wurde TLS 1.2 2008 spezifiziert, OpenSSL hat es 2012 mit Version 1.0.? implementiert, IO::Socket::SSL noch spaeter uebernommen: ich gehe davon aus, dass wir Probleme mit aelteren FHEM-Installationen kriegen, wenn wir das so belegen.

Der Argumentation kann ich nur sehr teilweise folgen. Aber ich schlage einen Kompromiss für HttpUtils vor, geht so:
* TLS bleibt in allen Versionen erlaubt
* SSL wird verboten - somit auch der zunächst unerwartete Rückfall auf ssl3

Also so:

Code Auswählen Erweitern


      my $sslVersion = AttrVal("global", "sslVersion", "!SSLv23:!SSLv3:!SSLv2");
#      my $sslVersion = AttrVal("global", "sslVersion", "SSLv23:!SSLv3:!SSLv2");


Das funktioniert bei mir. (Ja, sinnvollerweise sollten das mehrere Leute bei sich vorab testen.)

[rudolfkoenig]

my $sslVersion = AttrVal("global", "sslVersion", "!SSLv23:!SSLv3:!SSLv2");

Ich fuehle mich mit diesem Vorschlag unwohl, womoeglich verstehe ich nur die Bedeutung der Werte nicht.
Warum ermoeglicht das Verbieten einer Protokollversion in einem Client, dass eine Verbindug mit einem Server zustandenkommt?
Entweder gibt es einen Designfehler bei der Aushandlung des Protokolls, oder einer der beiden Implementierungen ist kaputt.
Ich hoffe, dass Ersteres nicht der Fall ist, und den zweiten Fall will ich nicht per Voreinstellung in FHEM loesen.

Deswegen ist mein Vorschlag, dass dieses Problem im konkreten Modul (Nina.pm) geloest wird, entweder hartkodiert, oder per sslVersion Attribut.

P.S.: was ist eigentlich die SSL_version Voreinstellung in deinem Fall (siehe perldoc IO::Socket::SSL)?

[curt]

Ich fuehle mich mit diesem Vorschlag unwohl, womoeglich verstehe ich nur die Bedeutung der Werte nicht.

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

Warum ermoeglicht das Verbieten einer Protokollversion in einem Client, dass eine Verbindug mit einem Server zustandenkommt?

* Der Zielserver liefert ausschließlich TLS 1.2 aus - das ist unumstößlicher Fakt.
* Dein Konstrukt erlaubt jede Nachfrage nach TLS, egal welcher Version - es müsste also immer gehen.
* Unsere Seite kommt aus unerfindlichen Gründen auf die Idee, mit ssl3 anzufragen.
* Eindeutiger Fehler ist auf unserer Seite, dass SSLv23 zugelassen wird - siehe Beweis.

Entweder gibt es einen Designfehler bei der Aushandlung des Protokolls, oder einer der beiden Implementierungen ist kaputt.

Ja, es ist eindeutig was kaputt. Dummerweise auf der Client-Seite, also unserer. Ein Vorredner erwähnte, dass bei ihm unter genau gleichen Voraussetzungen curl nicht mitspielen mag ...

P.S.: was ist eigentlich die SSL_version Voreinstellung in deinem Fall (siehe perldoc IO::Socket::SSL)?

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

[CoolTux]

Code Auswählen Erweitern

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES128-GCM-SHA256
Das ist alles was der Server hinter warnung.bund.de erlaubt. Das ist schon ein ziemlich enges Korsett.
openssl s_client -connect warnung.bund.de:443

Ich kann mir Vorstellen das die SSL Implementierung in Perl Probleme mit dem korrekten aushandeln hat. Obwohl das ja eigentlich die OpenSSL Bibliothek an Ende macht.
Als erstes wäre Interessant wie genau die Verhandlungen aussehen ob es hier zu Problemen kommt.


Ich stimme aber Rudi zu. Es gibt von 5000 aktiven Usern und davon über 1000 die z.B. Weather mit SSL verwenden jetzt aktuell 3-5 wo Ihr Euch gerade die Arme für aus reißt.
Natürlich sollen auch die 5 Spaß an FHEM haben, aber zu einem verträglichen Aufwand. Daher wäre meine Empfehlung ganz klar das ändern der Konfig im Modul selbst. Das NINA Modul verbindet sich mit dem Server vom Bund und dieser Server hat eine bestimmte/besondere Konfig, nicht mal das ausschließlich TLSv1.2 das findet man viel, aber nur einen einzigen Cipher zu erlauben ist schon hart.


Grüße

[curt]

Das ist alles was der Server hinter warnung.bund.de erlaubt. Das ist schon ein ziemlich enges Korsett.

Yepp.
Der fragliche Server ist gar nicht für die Öffentlichkeit, wir greifen da das Gate für die Kommunikation der App "Nina" ab, also Katastropenwarnungen. (Die Subdomain ist öffentlich insoweit, dass jeder Webbrowser ein schönes html erhält - aber Browser sind eher uptodate.)

Ich stimme aber Rudi zu. Es gibt von 5000 aktiven Usern und davon über 1000 die z.B. Weather mit SSL verwenden jetzt aktuell 3-5 wo Ihr Euch gerade die Arme für aus reißt.

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.