SSL/HTTPS error kommen wieder im Log vor

[Burny4600]

Nur woher kommen die Handshake Fehlermeldungen und der Langsame Verbindungsaufbau.
Das System wurde auch schon komplett neu aufgebaut und es ist alles auf Letztstand.

[dev0]

Nur woher kommen die Handshake Fehlermeldungen und der Langsame Verbindungsaufbau.

Kannst Du nachweisen, dass es mit F2F zu tun hat oder tauchen sie "nur" in Deinem Log auf?

[Burny4600]

Ja kann ich.
Weil es nur telnet Verbindungen zu F2F gibt und auch nur diese IP Adressen auftauchen zu denen es F2F Verbindungen mit TLS gibt.

[dtavb]

Hoi,

in Deinem Verbindungsaufbau mit zwingender ssl3 suite steht:

Code Auswählen Erweitern

pi@ccs-ht-rasp01:~ $ openssl s_client -connect 192.168.17.184:7072 -ssl3
CONNECTED(00000003)
1995765856:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1315:SSL alert number 40
1995765856:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1502520065
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Alert 40 bedeutet wohl:
SSL alert number 40 means that the server won't accept the connection because no user certificate was presented. You have to specify the user certificate and the private key with the -cert and -key parameters.

Benutzer/Client Zertis werden doch soweit ich das aus Eurer Beschreibung verstehe gar nicht benötigt, Stichwort mtls.
Gibt es irgendwo eine Einstellung in einer Konfig-Datei (sei es fhem.cfg oder Linux) wo man das festschreiben kann?
fhem.cfg kann es fast nicht sein, denn Du schreibst, dass es via Linux CLI ebenfalls auftritt wenn Du die Option -ssl3 benutzt.

Auch macht mich stutzig, dass Deine Logs ausgeben:
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported

Null-Cipher sind gleich verschlüsselt mit Null und daher unverschlüsselt. Naja entschlüsselbar zumindest - man kennt ja den Schlüssel

Das ist aber alles eigentlich nicht so relevant, da Du ja die ssl3 Suite sowieso in fhem deaktiviert hast.
Evt. liegt das ganze Verhalten nur daran, dass zu best. Zeitpunkten eben ssl3 benutzt wird und die Handshake Fehler passieren.

Das Verhalten tritt bei all Deinen pi´s auf?

Als Idee:
Du könntest auf einem der Neben-Pis das ausführen (screen und tcpdump installieren via apt-get/aptitude):
screen
tcpdump -i any -C 10 -W 10 -w /tmp/trace_handshake.cap host A.B.C.D and port XYZ
Strg+a+d

Screen: kannst Die ssh session zum Pi wieder beenden und der tcpdump Befehl läuft in einer virt. Session im Hintergrund.
Via screen -list kannst Du die ID anzeigen lassen, via screen -r ID verbindest Du Dich in die Screen Session.
Via logout aus der Session, beendet Du diese oder restart des Pi (nicht neustart-persistent).

IP und Port muss noch gesetzt sein, Port ist wohl 22? Wenn Du das auf einem Neben-Pi absetzt, schnüffelt tcpdump den Netzverkehr auf der Maschine mit zur IP und Port mit. Es legt die Files unter /tmp/name.cap wie oben ab und erstellt ca. alle 10MB ein neues File und rotiert 10 Files (100MB), sprich bei dem bisschen Traffic wird das wohl locker eine Weile reichen.
So hast Du Zeit im Log auf den Fehler zu warten, ab und zu reinschauen und wenn er auftritt: das entsprechende Logfile anhand des Zeitstempels ausfindig machen und:
chown Dein-Linux-User /tmp/DATEI.cap
Die anderen Files nach dem Fehler sind dann noch wichtig, um nachzusehen wie schnell etc. die Gutfälle ausgehandelt werden, bzw. wie die Aushandlung auf Netzebene überhaupt aussieht im Gut wie im Schlechtfall.
Die Files kannst Du dann auch noch in 7zip als Archiv packen (alternativ direkt in Linux mit tar), das sind paar wenige kbytes als Anhang.

Das Anschauen kann ich gerne machen...keine Sorge böse Sache stehen da nicht drin.

Habe so einen Trace bei mir auch laufen, dummerweise bekomme ich gerade keinen Handshake Fehler reproduziert 

Nachtrag 16.8
Konnte Deinen Fehler nicht explizit bei mir nachstellen, aber etwas anderes was schon häufig im Forum genannt worden ist:
FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer:blablabla)
und
FHEMWEB SSL/HTTPS error: Connection reset by peer SSL accept attempt failed (peer:blablabla)

sorry

[Burny4600]

Danke für die Infos.
Aber dieses Thema muss ich noch weiter verfolgen.
Irgendwo ist mit HTTPS/SSL in FHEM noch der Wurm drinnen.

Vielleicht ist es nur ein Timeing Problem Aufgrund gewisser FHEM2FHEM Verbindungen die Zeitweise einen höheren Datenverkehr haben.
Ich merke schon nach einem Reboot des Systems unter FHEM mit HTTPS/SSL, wenn der Verbindungsaufbau der FHEM2FHEM Schnittstellen beginnt, das dieser mit HTTPS/SSL sehr lange dauert was ohne HTTPS/SSL sofort geschah.