Hallo Stefan,
da habe ich durchaus ein paar Anmerkungen/Ideen/Vorstellungen meinerseits:
StefanW hat geschrieben: ↑Do Feb 13, 2020 5:55 pm
Hallo Earl,
danke sehr, diese ständiges drehen an den Daumenschrauben des Browser Konsortiums ist echt anstrengend.
Vor allem, es bringt nur wenig. Den der wesentlichste Angriffspunkt ist ja nicht unbedingt die Authentifizierung oder die anschließende Verschlüsselung, sondern die Social Attacks auf die Anwender und der sorglose Umgang der Daten durch Serverbetreiber. Was nützt es, die Kreditkartendaten verschlüsselt zu übertragen, wenn diese anschließend unverschlüsselt in Datenbanken gespeichert sind die dann für alle offen in einem S3 Bucket zum download bereit stehen.
Einer der Hauptgründe für geringere Gültigkeit ist, dass nur so gewährleistet ist, dass kryptographische Fehler, die heute noch nicht bekannt sind wenigstens in absehbarer Zeit gefixt werden. Sei es z.B. die Anforderung an längere Keys oder eine neue Erstellung von Keys wegen Bekanntwerdens einer Schwäche wie z.B. Heartbleed.
StefanW hat geschrieben: ↑Do Feb 13, 2020 5:55 pm
Aber es nützt nichts, da müssen wir uns beugen und unsere Stammzertifikate neu generieren. Das Thema "import eigener Zertifikate" kommt damit auch wieder hoch wie auch die Überlegung, hier evt. doch mit LetsEncrypt zu arbeiten, da dies nun mittlerweile ein ausgereifteter Weg ist, zumal der angedachte Weg über SwissSign preislich schwer realisierbar ist.
Euer Stammzertifikat ist von der "neuen" Einschränkung nicht betroffen. Root CAs dürfen nach wie vor eine "unbegrenzte" Gültigkeit haben. Nur die davon signierten Zertifikate nicht.
Nach wie vor halte ich es aber für schwierig, dass ihr eure eigene CA betreibt, da ihr auch schon den Anforderungen an eine solche kaum gerecht werden könnt und es für euch wirtschaftlich kaum tragbar sein würde, zu versuchen diesen Gerecht zu werden. Damit halte ich es immer noch für ein Sicherheitsrisiko, dass es zwingend notwendig ist, eurer CA als root CA zu installieren und zu vertrauen.
Ein sinnvoller Weg, meines Erachtens nach, wäre der folgende:
1. ihr könnt eure CA mit samt der ausgelieferten Zertifikate für Wartungs-VPN und Support Zugriff auf die Wölfe verwenden. Ein binden des Zertifikats im Web-Server auf die IP-Adresse des Tunneladapters sollte kein all zu großer Aufwand sein.
Damit bleibt es auch bei euch, eure CA als Vertrauenswürdig einzustufen, und solltet eurer CA etwas "zustoßen", so müssen nicht hunderte oder gar tausende Endgeräte manuell gefixt werden (sofern man diese überhaupt informiert bekommt).
2. Der Zugriff mit auf die TWS UI kann wahlweise über HTTP und/oder HTTPS erfolgen. Im Heimnetzwerk gibt es hierfür nach wie vor nur in wenigen Fällen eine echte Anforderung hierfür. Einziges Risiko sehe ich nur bei Anwendern, die hier auf die Idee kommen Port 80 über Portforwarding aus dem Internet verfügbar zu machen. Wenn ihr dem zuvorkommen wollt, wäre ein Eintrag in der Firewall, der eingehende Verbindungen auf Port 80 nur von RFC 1918 Adressen aus zulässt eine einfache aber wirkungsvolle Möglichkeit.
Letzten Endes obliegt es aber in der Verantwortung des Benutzers, ob er sich für eine Verschlüsselte Übertragung (und den damit einhergehenden "Schwierigkeiten") entscheidet, oder eben nicht Es reicht hier meiner Meinung nach aus, auf der Login Seite beim Zugriff über HTTP einen entsprechenden Warnhinweis zu platzieren. Evtl. noch einen link auf die HTTPS Version.
Dies würde aber gleich mehrere eurer jetzigen Probleme lösen:
-andere Systeme, die z.B. Grafana einbinden wollen, dies aber nicht über HTTPS können, würden somit funktionieren.
-Allen, die Probleme mit der fix vorgegebenen Namensgebung haben, wäre damit geholfen.
3a. Solange der Zugriff ebenfalls über HTTP möglich ist, sind alle Optionen zur Verwaltung der Zertifikate im TWS lediglich ein Angebot eurerseits dies den Benutzern abzunehmen und HTTPS als Feature zu nutzen, eben mit den Einschränkungen die ihr heute auch habt bezüglich Vertrauensstellung eurer CA und die fixe Bindung an den von euch fest vorgegebenen Namen. Wem dieses Angebot so nicht passt, kann/muss dieses eben nicht nutzen, muss dann aber eben mit HTTP vorlieb nehmen.
3b. Gibt es definitiv keine Möglichkeit auch über HTTP auf den Wolf zuzugreifen, so ergeben sich einige bereits vor einiger Zeit diskutierte Anforderungen an die Verwaltung der Zertifikate:
- Dazu gehört auf jeden Fall die Möglichkeit das Zertifikat durch ein eigenes auszutauschen als absolutes Minimum.
- Einen Request zu erstellen (und dabei auch die SANs anzupassen) ist auf jeden Fall wünschenswert, aber nicht zwingend notwendig.
- Automatisch über eine Public CA wie Lets Encrypt ein Zertifikat zu erstellen und regelmäßig zu aktualisieren ist sicherlich die Kür, bringt aber wieder die Problematik mit der Namensauflösung mit sich, da hierfür ein Zugriff von Außen und die Verwendung eines Public DNS Namens von Nöten wird. Dies ist also nur in speziellen Fällen möglich und erfordert auf jeden Fall weitere Schritte seitens des Anwenders, was somit kaum vorauszusetzen ist als alleinige Möglichkeit ein Zertifikat zu erzeugen.
VG
Earl