Hallo.
Ich versuche auf meinen nextcloud-Kalender via Modul CALENDAR zuzugreifen.
define my_cal Calendar ical url https://tbone:password@mein.server.de/remote.php/dav/principals/users/tbone/defaultcalendar?export 3600
Leider versucht das Modul via SSLv3 einen Connect. Das stellt der Server aber nicht mehr zur Verfügung.
2016.12.20 17:12:44 1: Calendar my_cal: retrieval failed with error message <hidden>: Can't connect(2) to https://mein.server.de:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
2016.12.20 17:12:44 1: Calendar my_cal: retrieved no or empty data
Am Raspi sind die benötigten Perl Libraries gerade aktualisiert.
ii libgnutls-openssl27:armhf 3.3.8-6+deb8u3 armhf GNU TLS library - OpenSSL wrapper
ii libio-socket-ssl-perl 2.002-2+deb8u1 all Perl module implementing object oriented interface to SSL sockets
ii libnet-smtp-ssl-perl 1.01-3 all Perl module providing SSL support to Net::SMTP
ii libnet-ssleay-perl 1.65-1+deb8u1 armhf Perl module for Secure Sockets Layer (SSL)
ii libssl1.0.0:armhf 1.0.1t-1+deb8u5 armhf Secure Sockets Layer toolkit - shared libraries
ii openssl 1.0.1t-1+deb8u5 armhf Secure Sockets Layer toolkit - cryptographic utility
Weis jemand, wie man das Modul dazu bringt den Connect via TLS aufzubauen?
Danke im voraus,
Tbone
Hallo!
Mittlerweile habe ich herausgefunden, das im Modul 57_Calendar beim Connect zwar das SSLverify berücksichtigt wird, aber beim Connect mit der Methode new()http://search.cpan.org/dist/IO-Socket-SSL-1.77/SSL.pm#METHODS (http://search.cpan.org/dist/IO-Socket-SSL-1.77/SSL.pm#METHODS) keine SSL_version berücksichtigt wird. Default ist aber SSLv23. Bei Servern die SSLv3 und älter ablehnen, ist das ein Problem.
@Dr. Boris Neubert
Wäre es möglich, SSL_version in den Connect-String mit aufzunehmen, damit man auf einen aktuell abgesicherten Kalenderserver zugreifen kann?
Das Ganze noch via Attribut einstellbar zu machen, wär' natürlich die Krönung.
Vielen Dank im voraus,
Tbone
Zitat von: Tbone am 16 Januar 2017, 00:31:04
Default ist aber SSLv23
Kann es sein, dass Dein FHEM sehr lange oder noch nie ein Update gesehen hat oder dass Du das globale Attribut sslVersion gesetzt hast?
Zeig mal bitte die Ausgabe von 'list global'. In Code-Tags, bitte.
Servus.
Danke für den Tipp.
Aktualisiert habe ich vor meinem erneuten Anlauf, mit dem selben Ergebnis.
Internals:
DEF no definition
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2017-01.log
logfile ./log/fhem-%Y-%m.log
Attributes:
autoload_undefined_devices 1
configfile /opt/fhem/fhem.cfg
logfile ./log/fhem-%Y-%m.log
modpath .
statefile ./log/fhem.save
updateInBackground 1
userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
verbose 3
version fhem.pl:13054/2017-01-13
In der Hilfe zu gobal finde sich:
sslVersion
Specifies the accepted cryptography algorithms by all modules using the TcpServices helper module. The current default TLSv12:!SSLv3
Sollte doch passen, oder hab ich da vielleicht noch etwas übersehen?
Der Connect findet meiner Meinung nach via SSLv3 statt.
2017.01.16 11:58:55 1: Calendar tbone_cal: retrieval failed with error message <hidden>: Can't connect(2) to https://meinserver.de:443: SSL connect attempt failed because of handshake problems error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version SSL connect attempt failed because of handshake problems error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
Greetings,
Tbone
Zitat von: Tbone am 26 Januar 2017, 22:05:28
Der Connect findet meiner Meinung nach via SSLv3 statt.
Sieht für mich nach TLSv1 aus, dass durch den altuellen sslVersion Default nicht erlaubt ist.
Setz das Attribut sslVersion mal so, dass TLSv1 erlaubt ist oder dem Server TLSv12 beibringen.
Siehe auch: http://search.cpan.org/~sullr/IO-Socket-SSL-2.044/lib/IO/Socket/SSL.pod#Description_Of_Methods -> SSL_VERSION
Servus.
Ich hab mal, obwohl es eh default sein sollte
attr global sslVersion TLSv12
in der fhem.cfg drinnen, macht aber leider keinen Unterschied.
Der Server lehnt die Verbindung ab.
:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure SSL connect attempt failed because of handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Fehlt dem System (aktuelles Raspian) etwas um sich per TLS verbinden zu können? Im Fhem wüsste ich nicht mehr, was noch falsch sein kann.
-Tbone
TLSv12 kann ja nichts bringen, da TLSv12:!SSLv3 der atuelle FHEM Default ist, den Du nicht verändert hast.
Wie ich schon schrieb:
Zitat
Sieht für mich nach TLSv1 aus, dass durch den altuellen sslVersion Default nicht erlaubt ist.
Setz das Attribut sslVersion mal so, dass TLSv1 erlaubt ist oder dem Server TLSv12 beibringen.
Genau das dachte ich auch.
Wenn also TLS12 eh schon default st, warum baut FHEM dann laut Logfile eine SSLv3 Verbindung zum Kalenderserver auf?
Auf Grund eines fehlenden Perl-Moduls?
Wie kann ich das noch detaillierter troubleshooten?
-Tbone
Zitat von: Tbone am 31 Januar 2017, 13:25:04
Wenn also TLS12 eh schon default st, warum baut FHEM dann laut Logfile eine SSLv3 Verbindung zum Kalenderserver auf?
Die wird ja eben nicht aufgebaut:
Zitat
...SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
...SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Hast Du TLSv1 jetzt schon getestet oder nicht?
attr <dev> sslVersion TLSv1
Zitat
Wie kann ich das noch detaillierter troubleshooten?
Welche Protokolle und Versionen spricht Dein Webserver? Zumidnest eine Überlappung muss es mit den in FHEM erlaubten und verfügbaren übereinstimmen.
Welche verfügbar sind hängt (auch?) von Deiner ssllib ab. Ich habe aber nicht im Kopf was in Deiner 1.0.1t eingebaut ist.
Klingt, wie dev0 sagt, nach Nextcloud-Webserver. Wenn der von außen erreichbar ist, überprüf den mal mit https://www.ssllabs.com/ssltest. Dann siehst du, was der für SSL/TLS-Versionen annimmt. Und findest im Notfall auch noch Verbesserungspotential.
Vorab Danke,
dass ihr weitere Hinweise liefert, wo ich noch suchen könnte.
Der Calenderserver (aktuell Nextcloud 11.1) unterstützt derzeit folgende Protokolle:
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3 No
SSL 2 No
So, nun hab ich noch mehr Fragezeichen über dem Kopf, denn TLSv12 ist doch in den Globals das Default Protokoll.
(btw. Thunderbird, DAVdroid, iOS syncen alle ohne Probleme)
-Tbone
Kannst du mit wget/curl eine TLS Verbindung zu dem Webserver aufbauen?
Servus.
wget https://meinserver.de/remote.php/dav/principals/users/tbone/defaultcalendar?export
--2017-02-01 19:00:47-- https://meinserver.de/remote.php/dav/principals/users/tbone/defaultcalendar?export
Auflösen des Hostnamen »meinserver.de (meinserver.de)«... 192.168.47.1
Verbindungsaufbau zu meinserver.de (meinserver.de)|192.168.47.1|:443... verbunden.
Scheint also zu funktionieren. (abgesehen von der Authentifizierung nachher)
-Tbone
Ich habe auch keine Idee mehr und bin daher raus.
Vielleicht haben die HttpUtils.pm oder 57_Calendar.pm Maintainer noch eine Idee dazu:
Zitat
FHEM/HttpUtils.pm rudolfkoenig http://forum.fhem.de Automatisierung
FHEM/57_Calendar.pm neubert http://forum.fhem.de Unterstuetzende Dienste/Kalendermodule
Servus.
Selbiges Problem hab ich nun auch auf externen Webseiten(HTTPmod), sobald eine SSL Verbindung notwendig ist. Ich gehe also davon aus, das es an der Kombination Raspian/FHEM liegt - bzw. einem Perl Modul das dabei verwendet wird, denn wget funktioniert.
Hat jemand eine Idee dazu?
-Tbone
Zitat von: dev0 am 02 Februar 2017, 07:14:24
Ich habe auch keine Idee mehr und bin daher raus.
Vielleicht haben die HttpUtils.pm oder 57_Calendar.pm Maintainer noch eine Idee dazu: