ElabNET Technik Forum

Hallo Stefan
Wenn http, dann aber bitte komplett abschaltbar machen!
Zumal solche Devices vielleicht auch aus anderen (Sicherheits-)Gründen ersetzt werden sollten, sorry meine persönliche Meinung.
Und so eine T24 hat ja unter Umständen einen Fabrikationsstempel von 2012!

Hallo Daniel,

abeggled hat geschrieben: ↑Mo Jul 28, 2025 8:32 pm Zumal solche Devices vielleicht auch aus anderen (Sicherheits-)Gründen ersetzt werden sollten, sorry meine persönliche Meinung.
Und so eine T24 hat ja unter Umständen einen Fabrikationsstempel von 2012!

das kann man sicher alles diskutieren. Kostet aber alles Geld und funktionstüchtige Gerätschaften aus solchen Gründen auszutauschen ist auch nicht wirklich nachhaltig. Wenn es um solche Dinge geht, tausche ich auch meinen Multifunktionsdrucker aus, weil er die neuen Protokollstandards nicht mehr unterstützt und die alten unsicher sind. Grundsätzlich erfreue ich mich aber eher daran, dass ich mich in 2012 für eine hochwertige Kamera entschieden habe, die heute immer noch läuft. Wenn die mal den Geist aufgibt, werde ich mich um sinnvollen Ersatz kümmern, der dann auch wieder dem aktuellen Stand der Technik entspricht.

Beim Austausch müsste ich womöglich bauliche Veränderungen am Haus vornehmen. Will ich das? Da liegen die Hemmschwellen schon hoch.

Ich stimme dir da vollkommen zu, dass das dann pro Endpunkt konfigurierbar sein muss.

Wer hier mit welchen Devices welche Wege geht, muss jeder für sich ganz individuell selbst entscheiden. Ich mag da keine Grundsatzdiskussionen führen.

Wenn Elabnet zur Einschätzung kommt, dass dieser Eingangskanal nicht geöffnet wird, auch nicht optional, dann ist das eben so und ich habe das dann zu akzeptieren. Das war auch nicht als Forderung zu verstehen, sondern als Feedback.

Danke.

Beste Grüße
Jens

Ich hänge auch gerade an ähnlicher Stelle fest, wobei ich noch nicht 100%ig sicher bin (in der Architektur hängt der TWS aktuell zudem noch auf der WAN-Seite vom Unifi Gateway):
Ich versuche von der Unifi Console ein Webhook auf den TWS zu machen, der kommt leider nicht beim TWS an. Im Trace sieht man einen sauberen Verbindungsaufbau, TLS Handhake und Verbindungsabbau. Der naheliegende Verdacht ist, dass es daran liegt, dass Unifi dem Zertifkat nicht vertraut. Wie ich das TWS Zertifikat importieren kann, habe ich noch nicht herausgefunden.

Unabhängig vom konkreten (evtl. noch lösbaren) Fall oben macht es evtl. Sinn optional auch HTTP anzubieten- für Devices, die keinen Zertifikatsimport erlauben.

Und noch ne Anmerkung am Rande: Ich mag unverschlüsselte Protokolle auch nicht, eine Security-Bewertung ist aber immer im Gesamtkontext zu sehen.

Hi Jens und Jochen,

wir prüfen die - zuschaltbare - Implementierung für HTTP über Port 80 bereits im Entwicklungslabor.

Ein Problem dabei ist, dass der Timberwolf Server (schon immer) die HSTS Kennung ("HTTP Strict Transport Security") im Header ausliefert. Diese bedeutet "ich erlaube nur verschlüsselte Verbindungen". Jeder Client, der darauf achtet, wird sich nicht auf unverschlüsselt HTTP über Port 80 überreden lassen, weil der Timberwolf Server den Client entsprechend instruiert.

Darum wird man das auch keinen Testrequest per Browser auf http / 80 machen können, weil der Browser das HSTS auf jeden Fall beachten wird (und auch in seinem Cache zwischenspeichert). Dies soll "Man-in-the-Middle-Attacken" erschweren, weil ein Man-in-the-Middle nicht einfach einen Datenverkehr auf einen unverschlüsselten (und nicht mit Zertifikat gesicherten) Server umleiten kann, da der Browser sich gemerkt hat, dass dies für die Zukunft nicht erlaubt ist. Wir werden das daher auch nicht abschalten.

Bei wget gibt es wohl einen Parameter, dass dieses Tool das HSTS fallweise nicht beachten soll.

Eine Kamera von 2012 wird das HSTS gar nicht kennen und sich nicht dran stören. Beim Ubiquity müsste man das testen.

lg

Stefan

StefanW hat geschrieben: ↑Di Jul 29, 2025 5:25 pm Ein Problem dabei ist, dass der Timberwolf Server (schon immer) die HSTS Kennung ("HTTP Strict Transport Security") im Header ausliefert. Diese bedeutet "ich erlaube nur verschlüsselte Verbindungen". Jeder Client, der darauf achtet, wird sich nicht auf unverschlüsselt HTTP über Port 80 überreden lassen, weil der Timberwolf Server den Client entsprechend instruiert.

Das ist bei normalen Browsern auf jeden Fall ein Problem! Allerdings kann man die auch irgendwie dazu überreden, die Information wieder zu vergessen… was bestimmt kein Spass ist und wobei wahrscheinlich alles mögliche noch verloren geht…

Aber wie ist das bei alten Geräten? Ob die HSTS überhaupt schon kennen? Ob die das sauber cachen können? Ich habe keine effektive Erfahrung mit solchen Teilen, könnte mir nur vorstellen, dass man da was machen könnte…

Soooo alt ist HSTS ja nun auch nicht…

Gruß
Jochen

Wie reagiert denn eigentlich der TWS auf untrusted Certificates ?

Dragonos2000 hat geschrieben: ↑Di Jul 29, 2025 7:08 pmWie reagiert denn eigentlich der TWS auf untrusted Certificates ?

Falls damit gemeint ist, wie das neue Subsystem mit Zertifikaten des Clients umgeht?

Werden vom HTTP-Subsystem nicht geprüft (abschaltbar).

Es wäre sehr aufwändig, Update-Mechanismen von Root-Zertifikaten, zurückgezogenen Zertifikaten oder selbst erstellten Zertifikaten zu implementieren. Die Browser Hersteller haben damit schon Probleme (weshalb die Gültigkeit von Zertifikaten auf wenige Monate runtergedreht werden soll) und denen stehen Milliarden für die Entwicklung zur Verfügung.

lg

Stefan

Dragonos2000 hat geschrieben: ↑Di Jul 29, 2025 7:08 pm Wie reagiert denn eigentlich der TWS auf untrusted Certificates ?

Im Client Modus ist eine Checkbox mit der am die Prüfung des Zertifikates abschalten kann.

Viele Grüße,
Matthias

Auf das Feature freue ich mich wirklich, da fallen mir spontan eine ganze Reihe Anwendungen ein.

Bezüglich der Frage http ja oder nein bin ich bei @blaubaerli. Bei mir ist es z.B. auch eine T24, aber auch ein paar andere ältere Geräte. Warum sollte ich die Austauschen, sie sind von außen nicht erreichbar und können selbst auch nicht ins Internet kommunizieren. Außerdem hängen diese Geräte in meinem internen Netz in separaten VLANs, so dass auch andere Devices nicht einfach lauschen können.

Ja, das entspricht nicht der reinen Lehre, ist aber noch meiner persönlichen Risikoeinschätzung tragbar.

jockel hat geschrieben: ↑Fr Aug 01, 2025 9:30 amBezüglich der Frage http ja oder nein bin ich bei @blaubaerli. ... Ja, das entspricht nicht der reinen Lehre, ist aber noch meiner persönlichen Risikoeinschätzung tragbar.

Jep. Wir glauben an den mündigen Nutzer und vor allem an Nachhaltigkeit.

Man darf durchaus persönlich der Ansicht sein, dass ein Webhook, der über eine Bewegung / Klingel etc. informiert, im eigenen Netz nicht verschlüsselt sein muss. Vielleicht sollte man es sich verkneifen, daraufhin automatisch die Türe zu öffnen.

==> Kurz: Ist bereits eingebaut. Für eingehende HTTP-/REST-API Verbindungen ist pro Endpunkt einzeln konfigurierbar, dass auf Verschlüsselung fallweise verzichtet werden kann und nur HTTP/1.1 genutzt wird.

Das sieht dann so aus:




lg

Stefan

PS: Die IP 8 ist bereits verfügbar, an der gesamten Doku und Info-Forenbeitrag wird noch gearbeitet