@rudolfkoenig
Bei genau einem Modul wird bei mir (und offenbar nur bei mir) ssl3 aufgerufen. Das geht schief, der Zielserver lehnt ab. Verständlich.
Zitat
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?
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.
Zitat von: curt am 20 Juli 2019, 04:07:21
@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.
Zitat von: rudolfkoenig am 20 Juli 2019, 11:01:02
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?
Zitat von: rudolfkoenig am 20 Juli 2019, 11:01:02
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.
Zitat von: rudolfkoenig am 20 Juli 2019, 11:01:02
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
$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.
Zitat von: rudolfkoenig am 20 Juli 2019, 11:01:02
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?
@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:
# 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.
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)
ZitatVmtl. sollte dieses Attribut auch in 77_Nina.pm eingebaut werden.
halte ich auch für den falschen Weg.
ZitatDann wird an Modulen gefrickelt werden - es muss aber systemisch an der Wurzel sein
So sehe ich das auch.
Ich könnt natürlich
im Modul sslargs => { SSL_version => 'TLSv12' }einbauen.
Zu Nebenwirkungen fragen Sie bitte Ihren Arzt oder Apotheker. :-\ ;)
ZitatIn der Zwischenzeit habe ich viel gelesen, recherchiert, in FHEM getestet.
Und damit haette FHEM seinen ersten SSL-Experten :)
ZitatIch habe dort [...] auskommentiert. War das gemeint?
Nein, damit hast du nur die Moeglichkeit, in einem Modul sslVersion zu setzen, entfernt.
Ich meinte Folgendes:
--- 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}};
Zitatmy $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.
Zitat> 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.
@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.
@KölnSolar
Zitat von: KölnSolar am 21 Juli 2019, 09:20:09
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
Zitat von: KölnSolar am 21 Juli 2019, 09:20:09
Ich könnt natürlich 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.
@KyleK
Zitat von: KyleK am 21 Juli 2019, 23:24:50
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 ...)
Zitat von: rudolfkoenig am 21 Juli 2019, 10:17:02
ZitatIn 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.
Zitat von: rudolfkoenig am 21 Juli 2019, 10:17:02
- 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.
Zitat von: rudolfkoenig am 21 Juli 2019, 10:17:02Laut 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:
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.)
Zitatmy $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)?
Zitat von: rudolfkoenig am 22 Juli 2019, 09:27:43
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.
Zitat von: rudolfkoenig am 22 Juli 2019, 09:27:43
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.
Zitat von: rudolfkoenig am 22 Juli 2019, 09:27:43
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 ...
Zitat von: rudolfkoenig am 22 Juli 2019, 09:27:43
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.
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
Zitat von: CoolTux am 22 Juli 2019, 09:49:03
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.)
Zitat von: CoolTux am 22 Juli 2019, 09:49:03
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.
ZitatSSLv23 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.
ZitatThe 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.
ZitatRudolf, 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 :)
Zitat von: curt am 22 Juli 2019, 09:59:39
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
Zitat von: rudolfkoenig am 22 Juli 2019, 10:00:37
Zitat
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.
Zitat von: CoolTux am 22 Juli 2019, 10:21:15
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?
Zitat von: CoolTux am 22 Juli 2019, 09:49:03
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)
Will nochmal festhalten, dass das Problem nur auf bestimmten Clients auftritt, da ich mit
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":
Zitat...
* 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.
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
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?
openssl ciphers -v | grep TLSv1.2
Zitat von: CoolTux am 22 Juli 2019, 12:07:52
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?
openssl ciphers -v | grep TLSv1.2
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=SHA256dietpi@fhem:~$ openssl version
OpenSSL 1.1.1c 28 May 2019
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
Sollte also laut openssl funktionieren.
Zitat von: CoolTux am 22 Juli 2019, 13:11:10
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
Sollte also laut openssl funktionieren.
nicht eher deswegen?
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
Zitat von: frank am 22 Juli 2019, 14:00:59
nicht eher deswegen?
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
Doch hast Recht. Genau deswegen. Danke Dir
@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:
# 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.
Und welche openssl Version hast Du? Welches System (Distrie)?
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/
Ich bin da erstmal raus. Persönlich bleibe ich bei meiner Meinung bezüglich Änderungen.
Was ich aber machen werde. Am Wochenende installiere ich Buster in meiner Testumgebung und schaue ob dies eine generelle Einschränkung ab dieser openssl Version/Debian Buster ist.
Grüße
Zitat von: CoolTux am 23 Juli 2019, 08:22:48
Persönlich bleibe ich bei meiner Meinung bezüglich Änderungen.
Die ist von Interesse - magst Du sie konkret wiederholen?
Sachstand ist ja dieser:
* (Im Moment) ist ein Modul mit einem Zielserver (ausgerechnet Hierarchie bund.de) betroffen.
Workarounds für Betroffene, alternativ:
* Hack in 77_Nina
* Hack in HttpUtils
* attr global
So richtig prima finde ich keine der Versionen.
Zitat von: CoolTux am 23 Juli 2019, 08:22:48
Am Wochenende installiere ich Buster in meiner Testumgebung und schaue ob dies eine generelle Einschränkung ab dieser openssl Version/Debian Buster ist.
Ok. - Du berichtest?
Zitat von: curt am 23 Juli 2019, 08:35:53
Die ist von Interesse - magst Du sie konkret wiederholen?
Sachstand ist ja dieser:
* (Im Moment) ist ein Modul mit einem Zielserver (ausgerechnet Hierarchie bund.de) betroffen.
Workarounds für Betroffene, alternativ:
* Hack in 77_Nina
* Hack in HttpUtils
* attr global
So richtig prima finde ich keine der Versionen.
Ich sehe die Sache nüchtern betrachtet. Es betrifft ein Modul! Dieses Modul ist inoffiziell! Es betrifft aktuell 2-3 User von 5000 welche eine gemeinschaftliche "Bibliothek" verwenden (HttpUtils). Es betrifft einen einzigen Server/Adresse warnung.bund.de! Die Auswirkungen einer "globalen" Änderung sind bisher unbekannt! Es gibt eine Lösung!!!
Zitat von: curt am 23 Juli 2019, 08:35:53
Ok. - Du berichtest?
Natürlich.
Ja, ich bin da auch völlig entspannt.
Mir war wichtig, das Thema hochzuziehen - auch unter dem Aspekt, dass das künftig häufiger auftreten könnte. Da haben wir jetzt schon einen Anker, das Problem ist als solches nun bekannt.
ZitatWorkarounds für Betroffene, alternativ:
* Hack in 77_Nina
* Hack in HttpUtils
* attr global
Oder ein Attribut in 77_Nina, was ich nicht als Hack bezeichnen wuerde. Es ermoeglicht einen Verbindugsaufbau fuer eine bestimmte Kombination von OpenSSL und Server, was vermutich auf eine fehlerhafte Interpretation des Protokolls auf einer der beiden Seiten zurueckzufuehren ist.
Zitat von: rudolfkoenig am 23 Juli 2019, 09:03:38
Oder ein Attribut in 77_Nina, was ich nicht als Hack bezeichnen wuerde.
Ja, genau das werde ich dem Modulautoren @KölnSolar nun vorschlagen. Bisher hatte ich ihn "warte mal bitte noch" davon zurückgehalten.
Gleichwohl sehe ich das als "übergangsweise".
Kurz zur Info. Anscheinend hat die openssl Version 1.1.1c aud Debian Buster Probleme mit dem Server.
Es wird immer versucht eine SSL3 Verbindung auf zu bauen.
Anscheinend ist der Server nicht in der Lage sich mit dem Client entsprechend zu unterhalten. Und ich rede hier von der aller ersten vorsichtigen Anfrage. Einen schüchternen "Hallo"
Jetzt musst du nur noch die richtigen RFCs durchlesen, um festzustellen, wer Mist baut :)
Zitat von: CoolTux am 26 Juli 2019, 16:12:49
Anscheinend ist der Server nicht in der Lage sich mit dem Client entsprechend zu unterhalten. Und ich rede hier von der aller ersten vorsichtigen Anfrage. Einen schüchternen "Hallo"
Ich finde schon, dass er in der Lage ist - lediglich weigert er sich konsequent, irgend etwas mit sslvx auch nur anzusehen. So ein Verhalten ist nicht so unüblich, lediglich bei public servern unerwartet.
Probiere mal bitte
openssl s_client -connect warnung.bund.de:443 -tls1_2
Er antwortet ganz artig.
Hi zusammen,
ich habe das Problem auch mit einem anderen Server - cloud.lancom.de, den ich mit httpmod abfragen möchte - auch dieser unterstützt lt. ssllabs.com nur TLS 1.2.
Ich habe nun schon versucht, die Version per SslVersion einzustellen:
sslVersion = !TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2
Geht aber nicht - was ist denn nun die Lösung für das Problem? Irgendwie konnte ich das hier im Thread nicht rauslesen...
Grüße
Magic01
Ich habe bei mir sslVersion auf "!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2" eingestellt. Damit geht zumindest der Bund.de Server.
ich hab da ein Problemchen mit
egal in welcher Konfiguration ich TLSv1_2 mit ins global Atribut packe, ich bekomme einen schicken neustart von Fhem wenn ich versuche "update" auszuführen.
im Log steht dann
Can't call method "timeout" on an undefined value at FHEM/HttpUtils.pm line 914.
Einzig das von der frischen Installation von Fhem (auf Buster) vorgegebenen Atributs reihe "SSLv23:!SSLv2:!TLSv12:!SSLv3" bekomme ich
"https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443: SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure"
habe das Update Problem bereits hier https://forum.fhem.de/index.php/topic,75923.msg968995.html#new (https://forum.fhem.de/index.php/topic,75923.msg968995.html#new) angesprochen und wurde dann auf diesen Thread hingewiesen.
Leider sind die Beiträge in diesem bislang noch nicht für mein Problem zielführend. :(
gibts hier eine Lösung die auf paspbian buster läuft?
gibts noch keine Lösung?
Lösung gibt es vermutlich schon, nur die, die es kennen, halten sich zurueck.
- funktionert update mit HTTP (was die Voreinstellung ist)?
- warum bist Du der Ansicht, dass Setzen des global Attributes auf diesem Wert helfen sollte?
- wie schaut ein "attr global verbose 5" Log Mitschnitt der Problems aus?
Zitat von: rudolfkoenig am 25 August 2019, 11:41:02
Lösung gibt es vermutlich schon, nur die, die es kennen, halten sich zurueck.
- funktionert update mit HTTP (was die Voreinstellung ist)?
Hallo Herr Koenig
per http, also wenn ich das global ssl atribut rausnehme läuft das update problemlos
Zitat von: rudolfkoenig am 25 August 2019, 11:41:02
- warum bist Du der Ansicht, dass Setzen des global Attributes auf diesem Wert helfen sollte?
ich habe die Versuche aus diesem Thread ausprobiert weil es in dem Thread eben um Updates geht und ich keinen anderen Ansatz mehr hatte um Fehler
auszuschließen. habe bereits (wie im anderen Thread beschrieben einiges anderes probiert:
- ich hab libio-socket-ssl-perl reinstalliert um ein Problem damit (ja hab im Forum schon einige Tage gesucht) auszuschließen.
- ich hab getestet ob dns Auflösung funktioniert (ja)
- ich hab geprüft ob die Kiste ssh nach draußen kann (ja)
- ich hab ssl v2 und v3 aus den global atributen rausgenommen, obgleich auf den 2 noch verbliebenen wheezy's mit v2 und v3 funktioniert
- ich hab die Gruppenzugehörigkeit geprüft
Zitat von: rudolfkoenig am 25 August 2019, 11:41:02
- wie schaut ein "attr global verbose 5" Log Mitschnitt der Problems aus?
das sieht dann so aus:
2019.08.28 09:50:50 5: Starting notify loop for global, 1 event(s), first is ATTR global verbose 5
2019.08.28 09:50:50 5: createNotifyHash
2019.08.28 09:50:50 5: End notify loop for global
2019.08.28 09:50:50 5: Cmd: >{AttrVal("global","room","")}<
2019.08.28 09:50:53 5: Cmd: >update<
2019.08.28 09:50:53 5: Loading ./FHEM/98_update.pm
2019.08.28 09:50:54 3: telnetForBlockingFn_1566978654: port 39283 opened
2019.08.28 09:50:54 4: BlockingCall (doUpdateInBackground): created child (17404), uses telnetForBlockingFn_1566978654 to connect back
2019.08.28 09:50:56 5: HttpUtils url=https://fhem.de/fhemupdate/controls_fhem.txt
2019.08.28 09:50:56 4: Connection accepted from telnetForBlockingFn_1566978654_127.0.0.1_38692
2019.08.28 09:50:56 5: Cmd: >{Log('1','https://fhem.de/fhemupdate/controls_fhem.txt: Can\'t connect(2) to https://fhem.de:443: SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure')}<
2019.08.28 09:50:56 1: https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443: SSL connect attempt failed error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
2019.08.28 09:50:56 5: Cmd: >{BlockingStart('1')}<
2019.08.28 09:50:56 5: Cmd: >{updDone('0')}<
sslVersion zu aendern empfehle ich nur diejenigen, die wissen, was es bewirkt, ich selbst z.Bsp. weiss es nicht (genau genug).
Ist evtl. ein Proxy im Weg?
Evtl. hilft die Ausgabe der folgende Skripte zu studieren:
https://raw.githubusercontent.com/noxxi/p5-ssl-tools/master/analyze-ssl.pl
https://labs.portcullis.co.uk/tools/ssl-cipher-suite-enum/
Was hast Du denn jetzt im attr global sslVersion?
Zitat von: rudolfkoenig am 28 August 2019, 20:14:02
sslVersion zu aendern empfehle ich nur diejenigen, die wissen, was es bewirkt, ich selbst z.Bsp. weiss es nicht (genau genug).
Ist evtl. ein Proxy im Weg?
Evtl. hilft die Ausgabe der folgende Skripte zu studieren:
https://raw.githubusercontent.com/noxxi/p5-ssl-tools/master/analyze-ssl.pl
https://labs.portcullis.co.uk/tools/ssl-cipher-suite-enum/
Ich habe keinen Proxy im heimischen Netzwerk, außerdem haben meine anderen beiden PIs (mit unipian image wegen unipi Board) keinerlei Problem mit den gleichen Settings aus dem gleichen Netz das Update zu fahren.
Zitat von: amenomade am 29 August 2019, 01:50:36
Was hast Du denn jetzt im attr global sslVersion?
attr global sslVersion SSLv23:!SSLv2:!TLSv12:!SSLv3
Ich habe bei mir
attr global sslVersion !TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2
gesetzt und bisher keine Probleme mit dem Update. Es ist also nur TLSv1_2 aktiv.
Zitat von: devien am 29 August 2019, 14:29:48
attr global sslVersion SSLv23:!SSLv2:!TLSv12:!SSLv3
Damit ist nur SSL v2.3 erlaubt und TLSv1.2 nicht.
Da der Fhem Server TLS v1.2 verschlüsselung benutzt, kannst Du keinen Zugriff haben
Mit
!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2 wie bei mahowi ist alles verboten ("!" vor dem Protokol) bis auf TLSv1_2. Somit funktioniert Fhem Update und meiste Webserver (die andere Protokole sind so wie so weniger sicher)
Zitat von: rudolfkoenig am 28 August 2019, 20:14:02
Evtl. hilft die Ausgabe der folgende Skripte zu studieren:
https://raw.githubusercontent.com/noxxi/p5-ssl-tools/master/analyze-ssl.pl
https://labs.portcullis.co.uk/tools/ssl-cipher-suite-enum/
hier mal die ausgabe von analyze-ssl.pl
pi@NikitaHWR1:/opt/fhem $ sudo ./analyze-ssl.pl -v 5 fhem.de:443
+ checking host=fhem.de(88.99.31.202 2a01:4f8:10a:806::2) port=443
* version SSLv23 no verification, ciphers= -> TLSv1_2,ECDHE-RSA-AES128-GCM-SHA256
* version SSLv23 no verification, ciphers=HIGH:ALL -> TLSv1_2,ECDHE-RSA-AES128-GCM-SHA256
* version TLSv1_2 no verification, ciphers= -> TLSv1_2,ECDHE-RSA-AES128-GCM-SHA256
* version TLSv1_2 no verification, ciphers=HIGH:ALL -> TLSv1_2,ECDHE-RSA-AES128-GCM-SHA256
* version TLSv1_1 no verification, ciphers= -> TLSv1_1,ECDHE-RSA-AES128-SHA
* version TLSv1_1 no verification, ciphers=HIGH:ALL -> TLSv1_1,ECDHE-RSA-AES128-SHA
* version TLSv1 no verification, ciphers= -> TLSv1,ECDHE-RSA-AES128-SHA
* version TLSv1 no verification, ciphers=HIGH:ALL -> TLSv1,ECDHE-RSA-AES128-SHA
+ successful connect with TLSv1_2, cipher=ECDHE-RSA-AES128-SHA, sni=fhem.de and no other TLS extensions
+ SNI success
* same certificate chain in without SNI
+ certificate verify success
+ OCSP stapling: no stapled response
<3> need to send 120 bytes OCSP request to http://isrg.trustid.ocsp.identrust.com
<3> need to send 122 bytes OCSP request to http://ocsp.int-x3.letsencrypt.org
+ all certificates verified
+ failed tcp connect to IP 2a01:4f8:10a:806::2: tcp connect: Network is unreachable at ./analyze-ssl.pl line 229.
* connect with version TLSv1_2 cipher ECDHE-RSA-AES128-GCM-SHA256
* connect with version TLSv1_2 cipher ECDHE-RSA-AES256-GCM-SHA384
<3> tried with cipher list 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:HIGH:ALL' -> ECDHE-RSA-AES128-GCM-SHA256
<3> tried with cipher list 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:ALL' -> ECDHE-RSA-AES128-GCM-SHA256
* server decides cipher order
-- fhem.de port 443
! failed tcp connect to IP 2a01:4f8:10a:806::2: tcp connect: Network is unreachable at ./analyze-ssl.pl line 229.
* maximum SSL version : TLSv1_2 (SSLv23)
* supported SSL versions with handshake used and preferred cipher(s):
* handshake protocols ciphers
* SSLv23 TLSv1_2 ECDHE-RSA-AES128-GCM-SHA256
* TLSv1_2 TLSv1_2 ECDHE-RSA-AES128-GCM-SHA256
* TLSv1_1 TLSv1_1 ECDHE-RSA-AES128-SHA
* TLSv1 TLSv1 ECDHE-RSA-AES128-SHA
* cipher order by : server
* SNI supported : ok
* certificate verified : ok
* chain on 88.99.31.202
* [0/0] bits=2048, ocsp_uri=http://ocsp.int-x3.letsencrypt.org, /CN=fhem.de SAN=DNS:cloud.fhem.de,DNS:commandref.fhem.de,DNS:conf.fhem.de,DNS:fhem-test.fhem.de,DNS:fhem.de,DNS:fhem.org,DNS:forum.fhem.de,DNS:svn.fhem.de,DNS:wiki.fhem.de,DNS:www.fhem.de
* [1/1] bits=2048, ocsp_uri=http://isrg.trustid.ocsp.identrust.com, /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
* [-/2] bits=2048, ocsp_uri=, /O=Digital Signature Trust Co./CN=DST Root CA X3
* OCSP stapling : no stapled response
* OCSP status : good
also grob überblickt sieht das aus als ob der Raspberry rauskommt mit ssl und kommunizieren kann...
mehr kann ich aber nicht wirklich erkennen.
Zitat von: amenomade am 29 August 2019, 15:14:36
Damit ist nur SSL v2.3 erlaubt und TLSv1.2 nicht.
Da der Fhem Server TLS v1.2 verschlüsselung benutzt, kannst Du keinen Zugriff haben
Mit
!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2 wie bei mahowi ist alles verboten ("!" vor dem Protokol) bis auf TLSv1_2. Somit funktioniert Fhem Update und meiste Webserver (die andere Protokole sind so wie so weniger sicher)
mit dem atribut bekomme ich:
https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout
also nochmal wie in https://forum.fhem.de/index.php/topic,34076.msg282099.html#msg282099 beschrieben die Rchte aktualisiert und siehe da, es läuft das update durch.
Ich hoffe dauerhaft, aber fürs erste bin ich zufrieden :)
vielen Dank @all