Fehler: Handshake failed with Client-ID 1

[saegefisch]

Es haben ja hier eine ganze Reihe an erfahrenen Nutzern einen ReverseProxy (NGINX) am laufen für den Zugriff auf edomi. Gerne möchte ich meine Frage an diese Runde noch einmal stellen:

• Wenn ich zu Port 8080 die Client Certifiactes (CC) auf "on" stelle, geht die Visu nicht mehr, schalte ich sie aus, geht die Visu umgehend wieder
• Zugriff von außen auf Port 8080 läuft per SSL.
• Da edomi hinter dem ReversProxy bei mir der einzige non-SSL-Dienst ist, läuft auch websocket dort ohne SSL.
• Zu edomi schützen die Client Certifiactes nach meinem Verständnis verlässlich und hinreichend sicher - bei meinen wenigen CC und stark gesicherten Zertifikaten ist ein Durchkommen vermutlich nur akademischer Natur, solange der Reverse Proxy stets aktuell gehalten wird und NGINX restriktiv eingestellt ist.
• Frage: Ergibt sich hier ein konkreter Angriffsvektor auf Port 8080 ohne CC?
• Oder ist die Websocket-Verbindung gefahrlos, weil sie erst nach dem Zugriff auf den CC-gesicherten Port 443 erfolgt? Da fehlt mir schlicht das tiefere Wissen, um das einschätzen zu können
• Falls Port 8080 ein Risiko ist: Wie kann man den Websocket ebenfalls per CC schützen? Oder anders? Wie habt Ihr das gelöst.

Und noch eine optische Nebensächlichkeit am Rande: Kann es sein, das mit Client Certificates die favicon.ico nicht gefunden wird? Deaktiviere ich die CC kurz, findet z.B. das iphone hingegen das favicon für das Lesezeichen. Hat jemand dazu auch schon Erfahrungen gemacht und eine Lösungen gefunden.

[WWebber]

Seit ich nun auch einen ReverseProxy am Laufen habe, kriege ich diese Handshake errors wieder.
Kann man diese spezielle Fehlermeldung irgendwie unterdrücken?
Wenn der client nicht geht, würde ich das sowieso am client selbst feststellen und ggfs neu einloggen.

[saegefisch]

• Frage: Ergibt sich hier ein konkreter Angriffsvektor auf Port 8080 ohne CC?
• Oder ist die Websocket-Verbindung gefahrlos, weil sie erst nach dem Zugriff auf den CC-gesicherten Port 443 erfolgt? Da fehlt mir schlicht das tiefere Wissen, um das einschätzen zu können
• Falls Port 8080 ein Risiko ist: Wie kann man den Websocket ebenfalls per CC schützen? Oder anders? Wie habt Ihr das gelöst.

Da ich weiterhin in loser Folge die Fehldermeldung

Handshake failed with Client-ID 1

im Error-Log habe, würde ich diese Fragen gerne noch mal einbringen. Hat jemand dazu eine Einschätzung und im besten Fall auch eine Lösung?

[MaPa]

Hallo Zusammen,
bin gerade dabei die alte Krücke HS3, nach und nach, abzuschalten.
Im EDOMI Testbetrieb bekomme ich jetzt auch den Fehler und sogar mehrmals am Tag.
Allerdings mit der PID15072 und bin mittlerweile nach 537 Fehler bei Client-ID 90 angelangt.
Gibt es irgendwelche Hinweise hierzu?

 [TABLE="border: 0, cellpadding: 0, cellspacing: 0"]
 	 		[TR]
 			[TD]2019-08-27 04:55:58[/TD]
 			[TD]744996[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 06:23:45[/TD]
 			[TD]093132[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 06:49:43[/TD]
 			[TD]892062[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 07:06:58[/TD]
 			[TD]128659[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 07:55:02[/TD]
 			[TD]720130[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 07:57:54[/TD]
 			[TD]825038[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 08:08:39[/TD]
 			[TD]600528[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2019-08-27 08:11:44[/TD]
 			[TD]396929[/TD]
 			[TD]VISU[/TD]
 			[TD]15072[/TD]
 			[TD]Handshake failed with Client-ID 90[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 	 [/TABLE]

top - 08:24:08 up 13 days,  1:06,  1 user,  load average: 0,18, 0,19, 0,22
Tasks: 150 total,   1 running, 149 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5,6 us,  1,4 sy,  0,0 ni, 92,8 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
KiB Mem : 16153504 total, 11743852 free,   520464 used,  3889188 buff/cache
KiB Swap:  8191996 total,  8191996 free,        0 used. 15236992 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
15072 root      20   0  300620  13428   7508 S  19,5  0,1   1670:58 php
 6104 mysql     20   0 1784252 255408   9192 S   5,3  1,6   1204:59 mysqld
15066 root      20   0  300620  13444   7520 S   2,6  0,1 427:52.69 php
15068 root      20   0  300796  13836   7896 S   1,7  0,1 241:48.46 php
15048 root      20   0  300620  13392   7464 S   1,0  0,1  95:48.95 php
 4939 root      20   0  573820  17300   6080 S   0,3  0,1   3:56.27 tuned
 7816 root      20   0  162012   2280   1588 R   0,3  0,0   0:00.18 top
15070 root      20   0  300620  13424   7500 S   0,3  0,1  12:26.95 php

[benji]

Hast du eventuell für den Port 8080 websocket ein Portforwarding eingerichet??

[Hendrik2020]

Moin, mal sehen ob der thread hier noch aktiv ist bzw. ob mir jemand helfen kann, ich bekomme sporadisch ohne logischen, nachvollziehbaren Grund die Fehlermeldung "Handshake failed with Client-ID..." die Firewall blockiert diesen Port nicht im LAN oder sonst wo... benutzt wird er auch von keinen anderen Geräten. Woran könnte es liegen oder wie könnte ich dem Fehler auf den Grund gehen?

[saegefisch]

Die Frage: Hast Du edomi aus dem WWW aktiv verfügbar gemacht und daher den Port 8080 in der Firewall von außen freigegeben? Nach meinem Verständnis sind dies Zugriffsversuche (Port-Scan,, ...) auf Port 8080, ohne dass eine legitime edomi-Session offen ist.

Solltest Du edomi nicht verfügbar gemacht haben, würde ich Dir dringend raten, Deine FW zu prüfen, ob nicht doch Ports freigeschaltet sind und sie schließen. Dann könnte es nur noch von "innen" kommen. Irgend ein Gerät oder Dienst greift auf Port 8080 ohne legitime edomi-Session zu -> Analyse LAN-Netzwerkwerkehr, um Quell-IP zu ermitteln.

Wenn es das auch nicht ist, gibt es offenbar einen anderen Auslöser für diese Meldung.
Ich habe sie sporadisch, wenn sie kommt, meist mehrfach an einem Tag. Dann wieder länger gar nicht. Ich versuch seit kurzem durch FW-Logs zu ermitteln, ob es tatsächlich zeitgleiche externe Zugriffe gibt und woher - bisher noch ohne Ergebnis..

[Hendrik2020]

nein, EDOMI ist durchs WWW nicht erreichbar, bzw. in den WAn und LAN Regeln finden sich dazu auch keine Regeln die was mit Port 8080 zutun haben könnten. Was für Programme gibts denn um meinen lokalen Netzwerkverkehr zu analysieren...?

[saegefisch]

Ich bin dazu auch eher interessierter Laie. Mein Router/FW von MikroTik erzählt meine Menge ("Torch", spezifische Log-Regeln einrichten,...) und hoffe, damit selber klarer zu sehen beim nächsten Vorkommnis.

Ohne derlei dürfte "wireshark" das Schweizer Messer dafür sein. Ich habe wireshark allerdings selber noch nie verwendet. Und das blöde ist vermutlich bei Dir wie bei mir: Die kommen nur sehr sporadisch. Aber vielleicht kann man wireshark auch als Dienst starten, der Port-Zugriffe auf 8080 auf Deine edomi-Maschine im Hintergrund dauerhaft protokolliert... und Du so der Quelle näher kommst.

[Hendrik2020]

okay, dann schaue ich das mal nach. Danke

[DJFalk]

Hallo zusammen,

nachdem ich meine WLAN Infrastruktur von Aruaba / HP Accesspoints auf Unifi umgestellt habe, tritt bei mir das selbe Problem auf.
Lustigerweise immer exakt zur selben Uhrzeit. Ich bin noch nicht so richtig schlau draus geworden, aber es sieht so aus, als ob der Fehler auftritt wenn sich mein Xiaomi Pad automatisch nachts runterfährt.

[Hendrik2020]

interessant, wir arbeiten schon immer mit Ubiquti AC's, dann wird das Problem wohl durch ein Update im Januar gekommen sein, oder ggf. durch eine neue Funktion. Hat noch jemand Ubiquti AC's und die Probleme? Wir benutzen iPads...

[saegefisch]

Wir haben keinerlei Ubiquti, sondern Mikrotik (Capsman) und haben dennoch die sporadischen Fehler. Leider nicht zu stets gleichen Zeiten und das letzte Vorkommnis ist bereits ein paar Tage her.
Visu ausschließlich auf ipad, iphone und PC oder Mac (keinerlei Android-Geräte in meinem Netzwerk)

Irgendwie keine Schnittmenge, um die Ursache einzugrenzen... :-/

[Hendrik2020]

könnte es möglicherweise sein, dass die "Endpoint Scans" die z.B. die UDM Pro durchführt den Fehler versuchen? Da führt sie ja einen "Scan" nach offenen Ports durch... kenne mich nicht all zu gut aus, aber das würde Sinn ergeben. Zeitlich passt das auch.

https://community.ui.com/questions/U...c-72a8b68545ac

[DerSeppel]

Könnte sein. Habe seit Freitag meine UDM Pro produktiv laufen und seit dem tritt der Fehler bei mir auf.
Macht ja Sinn, die UDM versucht eine Verbindung aufzubauen, ohne das Protokoll zu kennen. Das dürfte dann zu besagtem Fehler führen.