Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
08-05-2019, 23:14
Beitrag: #1
SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09-05-2019, 07:06
Beitrag: #2
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
Dann würde ich an deiner Stelle erstmal auf SSL verzichten, denn das läuft bei dir doch alles im internen Netz?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09-05-2019, 20:28
Beitrag: #3
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
(09-05-2019 07: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.)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11-05-2019, 11:18
Beitrag: #4
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
(09-05-2019 20: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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11-05-2019, 12:30
Beitrag: #5
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
17-05-2019, 16:05
Beitrag: #6
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
(11-05-2019 11:18)seagull schrieb:  
(09-05-2019 20: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.
Per eigenem Router, der vlan kann sollte das gehen. Geräte, die auf das Netz zugreifen müssen, sollten in beiden Netzen stehen.

(11-05-2019 12: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... Wink
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
21-05-2019, 23:17
Beitrag: #7
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
Zur Info, mittlerweile mittels reverse proxy gelöst, falls mal wer selbst vor dem Problem steht.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
22-05-2019, 14:44
Beitrag: #8
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
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?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
23-05-2019, 23:04
Beitrag: #9
RE: SSL-Verbindungszeit per Rest-Api, insb. mit neuer FW 3.x
(22-05-2019 14: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...rse-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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  Action URL mit neuer Firmware: gelöst. tomleitner 5 1.564 15-04-2019 19:42
Letzter Beitrag: rubinho
  Smart Home , Action URL Einbindung "Rest" Schnittstelle magusel 6 4.605 22-08-2018 12:28
Letzter Beitrag: kaiman55
  Neuer IP-Bereich Maggo 3 1.155 01-02-2017 13:21
Letzter Beitrag: Maggo
  Sortierung der Sensoren in neuer Firmware XT2Plus_lu-0.0.2.14L und neuer APP V1.3.3 Tekla 0 1.243 06-03-2016 10:12
Letzter Beitrag: Tekla
  NEUER DUAL BEWEGUNSMELDER ChegirDegir 0 1.464 11-12-2014 12:07
Letzter Beitrag: ChegirDegir



Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste