[patch] HttpUtils und SNI

Begonnen von wmr72, 02 Februar 2016, 14:28:24

Vorheriges Thema - Nächstes Thema

wmr72

Hallo,

die aktuelle Implementierung von HttpUtils hat aus meiner Sicht ein Problem wenn man NonBlocking-Requests auf TLS-Server macht, die SNI erfordern. In diesem Fall muss der Hostname explizit gesetzt werden, da die Verbindung per start_SSL() initiiert wird und der Server-Name nicht aus PeerAddr abgeleitet werden kann (siehe http://search.cpan.org/~sullr/IO-Socket-SSL-2.023/lib/IO/Socket/SSL.pod#Description_Of_Methods bei new()). Der folgende Patch behebt das für mich, ich habe allerdings nur meine Usecases getestet:


--- a/FHEM/HttpUtils.pm
+++ b/FHEM/HttpUtils.pm
@@ -202,6 +202,7 @@ HttpUtils_Connect2($)
{
   my ($hash) = @_;

+  $hash->{host} =~ s/:.*//;
   if($hash->{protocol} eq "https" && $hash->{conn} && !$hash->{hu_sslAdded}) {
     eval "use IO::Socket::SSL";
     if($@) {
@@ -213,6 +214,7 @@ HttpUtils_Connect2($)
       IO::Socket::SSL->start_SSL($hash->{conn}, {
           Timeout     => $hash->{timeout},
           SSL_version => $sslVersion,
+          SSL_hostname => $hash->{host},
           %{$hash->{sslargs}}
         }) || undef $hash->{conn};
       $hash->{hu_sslAdded} = 1 if($hash->{keepalive});
@@ -248,7 +250,6 @@ HttpUtils_Connect2($)
     }
   }

-  $hash->{host} =~ s/:.*//;
   my $method = $hash->{method};
   $method = ($data ? "POST" : "GET") if( !$method );


Das dürfte auch die Ursache für die unter http://forum.fhem.de/index.php/topic,48274.0.html beschriebenen Probleme sein.

Wolfgang

rubbertail

Hey Wolfgang,

Erfolg für o. g. Use Case! Vielen Dank! :)

Kann der breiter getestet werden? Und dann vielleicht eingecheckt? *indieRundeguck* :)

Ich werd bei mir mal versuchen, alles durchzutesten, und Rückmeldung geben, aber das ist halt nur Trial and Error - mach ich aber gern, wenns hilft.

Martin
FHEM auf Raspi, CUL433, CUL868, RFXTRX433e, CULCuBE
FRITZ: Fritzbox7590AX, 6xFritzDECT301, 10xFritzDECT200, FritzRepeater 6000
MAX!: Fensterkontakte
netatmo: Wetterstation & Thermostat
Milights, IT, Withings, HUE

rudolfkoenig


rubbertail

Ihr seid toll. Muss man mal sagen.
FHEM auf Raspi, CUL433, CUL868, RFXTRX433e, CULCuBE
FRITZ: Fritzbox7590AX, 6xFritzDECT301, 10xFritzDECT200, FritzRepeater 6000
MAX!: Fensterkontakte
netatmo: Wetterstation & Thermostat
Milights, IT, Withings, HUE

Christoph.Goth

Leider hat mir diese Änderung unter FreeBSD die Implementierung von SSL verhauen, Verbindungen zu SSL Ressourcen funktionieren nicht mehr.

Beispiel Updates:
fhemtabletui
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt: Can't connect(2) to https://raw.githubusercontent.com:443:  Client side SNI not supported for this openssl

Auch Verbindungen zu anderen SSL Ressourcen (Unifi WLan Controller) funktionieren nicht mehr.

Die OpenSSL Version auf dem Host ist OpenSSL 1.0.2f  28 Jan 2016, kann das also.
Die Perl Module sind auch alle korrekt vorhanden, wenn ich die HttpUtils nach einem Update wieder auf die alte Version drehe funktioniert alles.

rudolfkoenig

Seufz. Geht es um die neue LibreSSL, oder verwechsle ich da was?

Kannst du bitte folgendes rausfinden:
- Was ist $^O fuer FreeBsd (und OpenBSD?)
- Funktioniert es bei dir mit "SSL_hostname => undef,"


wmr72

Hm, im Zweifel könnte man wohl mit IO::Socket::SSL->can_client_sni() prüfen, ob die verwendete SSL-Bibliothek das auch kann.

rudolfkoenig

Bei mir kommt:
Can't locate object method "can_client_sni" via package "IO::Socket::SSL"

wmr72

Laut Changes ist das seit Version v1.84 (2013.02.15) in IO::Socket::SSL, der Code macht aber auch nicht mehr als das:
$can_client_sni = Net::SSLeay::OPENSSL_VERSION_NUMBER() >= 0x01000000;

rudolfkoenig

Ich frage mich, ob das bei LibreSSL auch so einfach funktioniert.

wmr72

Ich fürchte dass es eher noch komplizierter wird: ein System, das can_client_sni() nicht hat, ist vermutlich auch nicht neu genug, um überhaupt LibreSSL zu unterstützen. Es wäre wohl hilfreich wenn Christoph.Goth mal sagt, ob bei ihm wirklich LibreSSL unten drunter liegt oder doch die erwähnte "OpenSSL 1.0.2f", wobei ich dann nicht verstehen würde wie es zu seinem Problem kommt.

Christoph.Goth

LibreSSL ist auf dem System nicht installiert, es ist tatsächlich die OpenSSL Version aktiv soweit ich das sehen kann.
Neben der genannten Version ist noch eine OpenSSL 0.9.8za-freebsd 5 Jun 2014 auf dem System vorhanden, aber eigentlich deaktiviert. Diese kann aber auch bereits SNI, merkwürdig.

Die Perl Modul Version ist auch aktuell genug: IO::Socket::SSL 2.023

SSL_hostname => undef, --> Werde ich nachher mal ausprobieren was er dann bringt.

wmr72

Dann scheint hier aus irgendwelchen Gründen wohl noch die 0.9.8 aktiv zu sein, SNI ist erst ab Versionen >=1.0.0 enabled.