ElabNET Technik Forum

Guten Morgen liebe Community,

ich habe mal eine Frage zum leidigen Thema SSL bzw. TLS und Zertifikatsverwaltung.

Ich betreibe eine Visu auf basis von Node Red. diese wird via Timberwolf Proxy auf die URL https://timberwolf645.local/proxy/dashboard gelegt. Dabei ist timberwolf645.local der Name des Timberwolfs in meinem Netzwerk.

Nun ist es so, dass ich zwar auf meinem Mac und damit auch auf meinem iPhone über die Zertifikat Authority Funktion das Root Zertifikat von Timberwolf CA als "trusted" markieren kann, so dass die Browser auf beiden Geräten keine Probleme mit der Verbindung zur Seite haben. Dies gilt jedoch nicht für andere Geräte, insbesondere z.b. der (wirklich schlechte) Browser vom Amazon Echo TV 15.

Hier nun meine Fragen:

1. Gibt es irgend eine Möglichkeit diesen SSL Zwang im lokalen Netzwerk auszuschalten? (eventuell hab ich ja auch was falsch gemacht), da ich nicht glaube, dass Timerwolf eine globale Trusted Authority werden kann. Somit würden immer alle Zertifikate von der CA als "untrusted" gelten.

2. Wenn das nicht der Fall ist, könnte man irgendwie LetsEncrypt ins spiel bringen über z.b. einen DynDNS Dienst? Ich bin leider in diesen Gebieten nicht der Mega Experte, daher die Fragen.

Eventuell habt ihr ja alternative Lösungen und ich mache mir mein Leben nur viel zu kompliziert.

Liebe Grüße

Sebastian

Hallo Sebastian,

bitte passe den Betreff deines Threads noch gemäß der Forenregeln an und füge die Versionsangabe hinzu.

Danke.

Beste Grüße
Jens

Ich fände es auch sehr gut wenn man eigene TLS Zertifikate verwenden könnte.

Für ein durchaus sicherheitskritisches Produkt macht das auf jeden Fall Sinn - alles was man sich derzeit darum baut sind sonst Krücken.

TLS Zwang deaktivieren wäre dann noch ein Workaround in manchen Situationen. So wie es aktuell ist ist es halt wirklich etwas unbefriedigend.

Also von mir gibts ein +1 auf der Wunschliste für eigene Zertifikate.

Uwe

Hi Sebastian

Ich habe mal 1 und 1 zusammengezählt und [V3.5.1] im Titel ergänzt. Falls das nicht stimmen sollte bitte ändern oder als Post hier kommentieren.

Das Thema Zertifikate kenne und verstehe ich zwar aber ich bin leider nicht tief genug drin, um irgendwelche Lösungsansätze bieten zu können.

Hi Sebastian,

leider kennen wir keine einfache Lösung für das TLS Thema.

Es ist das Browser Forum, dass die Regeln festlegt und eben klare Vorgaben zur Authentifzierung macht. Dazu muss der Hostname mit demjenigen übereinstimmen, der im Zertifikat steht. Entsprechend liefern wir die Server mit Zertifikaten passend zu ihrem Hostnamen aus.

Wenn man nun kein TLS unterstützt oder die lokale Namensauflösung nicht schafft, muss man dem Browser eben sagen, dass man trotzdem eine Verbindung will und dann sollte das bei den meisten Browsern auch klappen. Insofern gibt es keinen Zwang.

Wir haben auf unserer Liste, dass man eines Tages eigene Schlüssel mit Zertifikaten installieren kann. Das hat den Vorteil, dass man nicht unserer CA vertrauen muss (bzw. müssen tut man ja nicht, dann geht es eben über die "ich will trotzdem zugreifen" Funktionen der Browser).

Bei dem ganzen TLS Thema haben de Browser-Hersteller die im lokalen Netz gehosteten Boxen vergessen bzw. haben auch keine gute Lösung dafür.

lg

Stefan

Hallo Stefan,

dem letzten Satz kann ich so nicht ganz zustimmen. Man kann auch als Privatperson Zertifikate erhalten, die von einer CA ausgestellt wurden, die per default in der Browser-CA-Liste enthalten sind und somit auch akzeptiert werden. Die Browser-Hersteller haben da also niemanden vergessen und tragen in Summe die geringste Verantwortung in der TLS Thematik. Die bilden nur ab, was eben so der Standard ist aktuell.

Das Problem sind schlichtweg die Self-Signed-Zertifikate, die Ihr mit dem Timberwolf ausliefert. Dass per se keine Self-Signed akzeptiert werden, ist sehr sinnvoll und nicht die Schuld der Browser.

Grundsätzlich könnte man das Problem aber einfach lösen:
1. Ihr liefert mit den Timberwolf-Servern offiziell signierte Zertifikate aus. (Sicherlich keine sinnvolle Lösung, da sollten wir uns einig sein)
2. Ihr erlaubt es den Anwendern selbst Zertifikate im Timberwolf zu hinterlegen.

Letzteres ist aus meiner Sicht die einzig richtige Variante. TLS aus, oder die Möglichkeit eigene Zertifikate zu hinterlegen. Self-Signed bietet in dem Umfeld absolut keinen Mehrwert, da der Anwender nicht Herr über das System ist. Nur um sagen zu können, dass die Verschlüsselung im eigenen Netz (!) aktiv ist, brauch ich dann auch kein TLS.

Bis dahin muss man dem Browser eben - wie du auch schreibst - sagen, dass man auf das Zertifikatsthema pfeift und einfach mal "blind" vertraut.

Ich vermute aber mal, dass das auch euren Support-VPN betrifft und das dann beim Wechsel auf eigene Zertifikate noch einmal ein Problem darstellen könnte.

Viele Grüße

Hi Stefan

StefanW hat geschrieben: ↑So Sep 03, 2023 7:30 pm Wir haben auf unserer Liste, dass man eines Tages eigene Schlüssel mit Zertifikaten installieren kann.

Wie weit unten steht das Thema auf der Liste?

Und in wiefern kann man über das Ausschalten von TLS nachdenken?

Weil ich da eine kleine Einschränkung habe, bezüglich der Root-CA Installation. viewtopic.php?p=53573#p53573

Hi Peer,

im Bereich Mitte bis oberes Drittel.

Wir wissen, dass vereinzelt Kunden eine andere Lösung brauchen. Wir haben ja einen Umbau des OS im Auge, dass dann auch IPv6 enthält und womöglich macht man das in diesem Zusammenhang, wobei ich hiermit nichts versprochen habe. Weil was einfach aussieht, ist nicht unbedingt einfach.

lg

Stefan

pbm hat geschrieben: ↑Mo Jan 29, 2024 7:25 am Und in wiefern kann man über das Ausschalten von TLS nachdenken?

Hallo Peer,

auch wenn deine Probleme nachvollziehen kann, ist meine persönliche Meinung, dass eine Deaktivierung von TLS die schlechteste Lösungsmöglichkeit ist. Der Wolf ist ein System mit allen möglichen Schnittstellen und kennt - je nach Setup - daher auch einige Credentials, ein solch zentrales System darf in meinen Augen nicht ungesichert agieren.

Wenn ich Stefan und sein Team wäre, würde ich diese Option nie anbieten, da sie im worst Case zu einer Support-Hölle führen wird:
Selbst mit deutlichen Warnungen, Disclaimern und ggf. sogar Einverständniserklärungen in einen Haftungsausschluss (sofern das juristisch überhaupt haltbar wäre) versehen kann ich mir jetzt schon vorstellen, dass es genügend User geben wird, die diese Option nutzen werden ohne sich zusätzlich abzusichern. Sollte es dann bei diesen Kunden zum Schadensfall durch einen Angriff kommen, werden sie trotz allem ganz schnell bei Elabnet mit Beschwerden und Ansprüchen (Support, Regress usw) auf der Matte stehen und sich auch ganz laut auf allen Plattform beschweren. Alleine um diesen Aufwand und Shitstorm vorbeugend zu vermeiden würde ich dieses Risiko erst gar nicht eingehen und die Option nicht einbauen. Und ja, wenn auch noch überschaubar, das Risiko existiert, siehe dazu auch [Hinweis] IT-Sicherheit am KNX-Bus.

Ergänzend dürfen wir nicht vergessen, dass es neben uns sicherlich auch den ein oder anderen Wolf in Gewerbeobjekten gibt, wo Sicherheit nochmal eine andere Rolle spielt, als im Privathaus.

Die Notwendigkeit einer Lösung für Fälle wie deinen stelle ich nicht in Abrede, aber die Deaktivierung von TLS ist mMn genauso wenig eine Lösung, wie Hintertüren für Strafverfolger in Verschlüsselungen von Kommunikationssystemen.

Hi Thorsten,

danke. Wir haben den ganzen Aufwand mit Crypto-Chip, Server-individuellen Keys, Verschlüsselung der Partition auch mit Hinblick auf die Gesetzeslage und die Verarbeitung personenbezogener Daten gemacht.

Es wird auch das Flag gesetzt, dass die Browser sich merken sollen, dass der TWS ausschließlich via TLS erreicht werden kann, eine Umstellung wäre schon aus diesem Grund schwierig, weil Browser, die einmal mit dem TWS per TLS verbunden waren, es ablehnen würden sich jemals ohne TLS zu verbinden.

Alles andere was Du gesagt hast, kommt noch oben drauf. Das einzige, worüber wir nachdenken, sind kundeneigene Zertifikate.

lg

Stefan