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

[CoolTux]

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

[curt]

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.

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?

[CoolTux]

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!!!

Ok. - Du berichtest?

Natürlich.

[curt]

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.

[rudolfkoenig]

Workarounds 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.

[curt]

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".

[CoolTux]

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.

[CoolTux]

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"

[rudolfkoenig]

Jetzt musst du nur noch die richtigen RFCs durchlesen, um festzustellen, wer Mist baut

[curt]

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

Code Auswählen Erweitern


openssl s_client -connect warnung.bund.de:443 -tls1_2


Er antwortet ganz artig.

[Magic01]

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

[mahowi]

Ich habe bei mir sslVersion auf "!TLSv1:!TLSv1_1:TLSv1_2:!SSLv23:!SSLv3:!SSLv2" eingestellt. Damit geht zumindest der Bund.de Server.

[devien]

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

Code Auswählen Erweitern

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 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?

[devien]

gibts noch keine Lösung?

[rudolfkoenig]

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?