+- Alarmanlagen-Forum - Alarmforum - Fachforum für Sicherheitstechnik (https://www.alarmforum.de)
+-- Forum: Einbruchmeldesysteme nach Hersteller (/forumdisplay.php?fid=97)
+--- Forum: LUPUS Electronics (/forumdisplay.php?fid=166)
+---- Forum: LUPUSEC XT2 (/forumdisplay.php?fid=161)
+---- Thema: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x (/showthread.php?tid=15540)
SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - bastelheini - 08-05-2019 22:14
Insbesondere mit der neuen FW ist mir aufgefallen, dass die Verbindungszeit unter Nutzung von SSL zur Anlage extrem lange dauert. Das merkt man eben, wenn man Dinge auslesen / steuern will - z.B. über einen Raspi. Der Handshake dauert ca 3 Sekunden und ich habe die vermeintlich potentere XT3.
Es liegt auch nicht am lahmen Raspi, wie ich erst dachte - auch vom PC aus ist es identisch.
Könnt ihr, die auch was eigenes angebunden haben, das nachvollziehen? Jeder neue Verbindungsaufbau ist lahm - ab dem zweiten Call mit der offenen Verbindung ist es schnell (im Browser sieht man das gleiche).
Per PHP & Co könnt ihr das einfach auslesen; wenn ihr das per curl - über curl_getinfo in die pretransfer_time schauen...
Was habt ihr für Werte. Ich denke mal, in der neuen FW sind einige unsicherere Ciphers raus, so dass die jetzt verbliebenen mit AES die Anlage überfordern. Doof, wenn man so Steckdosen schalten will und das dann jedes mal 3-4 Sekunden dauert bis zur Reaktion.
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - Torte - 09-05-2019 06:06
Dann würde ich an deiner Stelle erstmal auf SSL verzichten, denn das läuft bei dir doch alles im internen Netz?
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - bastelheini - 09-05-2019 19:28
(09-05-2019 06:06)Torte schrieb: Dann würde ich an deiner Stelle erstmal auf SSL verzichten, denn das läuft bei dir doch alles im internen Netz?
Ja, es läuft im lokalen Netz. Aber Nein, das lokale Netz ist keine DMZ - und gerade wenn sicherheitsrelevante Daten (Login in die EMEA, Requests & Responses) rumgehen, gehört es verschlüsselt, egal von wo. (...und idealerweise in ein eigenes Subnetz.)
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - seagull - 11-05-2019 10:18
(09-05-2019 19:28)bastelheini schrieb: (...und idealerweise in ein eigenes Subnetz.)
Wie hast du das umgesetzt. Ich hatte auch eine Routerkaskade versucht, indem die XT2 plus (damals noch) und die Kameras in einer untergeordneten Fritzbox angemeldet war. Das Problem war jedoch, dass dann mein VPN-Zugang nicht mehr funktionierte und ich weder auf Kameras noch die Alarmanlage von außen Zugriff hatte. Hast du einen Rat, wie das funktionieren könnte?
Vielen Dank
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - the-professor - 11-05-2019 11:30
Ansatz von Dir ist richtig, im Falle der XT1/2/3 aber sinnlos, da auf jeder Box der gleiche SSL-Schlüssel benutzt wird und jeder den Key aus der Firmware extrahieren kann. Somit kann jeder mitgeschnittenen Traffic der XT1/2/3 super simpel entschlüsseln.
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - bastelheini - 17-05-2019 15:05
(11-05-2019 10:18)seagull schrieb:Per eigenem Router, der vlan kann sollte das gehen. Geräte, die auf das Netz zugreifen müssen, sollten in beiden Netzen stehen.(09-05-2019 19:28)bastelheini schrieb: (...und idealerweise in ein eigenes Subnetz.)
Wie hast du das umgesetzt. Ich hatte auch eine Routerkaskade versucht, indem die XT2 plus (damals noch) und die Kameras in einer untergeordneten Fritzbox angemeldet war.
(11-05-2019 11:30)the-professor schrieb: Ansatz von Dir ist richtig, im Falle der XT1/2/3 aber sinnlos, da auf jeder Box der gleiche SSL-Schlüssel benutzt wird und jeder den Key aus der Firmware extrahieren kann. Somit kann jeder mitgeschnittenen Traffic der XT1/2/3 super simpel entschlüsseln.
Prinzipiell hast du recht - aber es verhindert das grobe Fischen und die meisten derartigen "Angriffsanwendungen" fischen nur Zugangsdaten (viele Leute nehmen die gleichen PW usw).
Das mit dem eigenen Zert sollte aber asap von Lupusec gelöst werden, ist schon ein Witz... Die sollten endlich mal 1-2 Leute mit Know How reinholen, was Netz- und Applikationssicherheit angeht. Neben dem UXer...
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - bastelheini - 21-05-2019 22:17
Zur Info, mittlerweile mittels reverse proxy gelöst, falls mal wer selbst vor dem Problem steht.
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - Torte - 22-05-2019 13:44
Ich habe zwar mal bei Wikipedia nachgeschlagen, aber kannst du netterweise noch ein paar Infos mehr zu deiner Lösung mit dem Reverse Proxy geben?
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x - bastelheini - 23-05-2019 22:04
(22-05-2019 13:44)Torte schrieb: Ich habe zwar mal bei Wikipedia nachgeschlagen, aber kannst du netterweise noch ein paar Infos mehr zu deiner Lösung mit dem Reverse Proxy geben?
Klar. Ich nutze einfach den nginx, der sowieso schon auf dem Raspi als Webserver läuft, um die Verbindung zur XT zu halten.
Vorher:
Direkte Kommunikation mittels Script per Curl an die XT über https://IP-DER-XT/request. Nach jedem Script-Ende wurde die Verbindung geschlossen - neuer Start = neuer SSL-Handshake = 3s Zeitverlust. Und bei einer Webanwendung mit XHR summiert sich das, da jeder Mini-Call ein Scriptaufruf ist.
Dieser Aufruf wird umgestellt auf einen Pfad, der direkt auf dem Raspi liegt, z.B. https://raspi/xt - dort lauscht der nginx und tunnelt die eingehenden Requests zur XT durch, forciert per http1.1 - und damit persistent per default. Da der nginx ja dauerhaft läuft, hält der die Verbindung auch.
https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
D.h. in der Art wie hier inkl. Absicherung, dass man es nur innerhalb des Raspis nutzen kann. Wenn doch gewünscht, müssen die ersten beiden Zeilen im Block weg.
Code:
location /xt/ {
allow 127.0.0.1;
deny all;
proxy_http_version 1.1;
proxy_pass https://IP-DER-XT/;
}Da per default ssl_verify ausgeschaltet ist, gibts auch keinen Stress mit dem selfsigned cert der XT.
Per cronjob kann man immer mal wieder eine Verbindung aufbauen; um ggf. eine neue zu erzeugen, falls sie doch mal abgerissen ist.