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 (http://forum.fhem.de/index.php/topic,48274.0.html) beschriebenen Probleme sein.
Wolfgang
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
Habs eingecheckt.
Ihr seid toll. Muss man mal sagen.
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.
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,"
Hm, im Zweifel könnte man wohl mit IO::Socket::SSL->can_client_sni() prüfen, ob die verwendete SSL-Bibliothek das auch kann.
Bei mir kommt:
Can't locate object method "can_client_sni" via package "IO::Socket::SSL"
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;
Ich frage mich, ob das bei LibreSSL auch so einfach funktioniert.
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.
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.
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.
Siehe https://forum.fhem.de/index.php/topic,51503.msg432224.html#msg432224