Das Problem mit den Zertifikaten
« | 30 Nov 2018 | »Und? Bei euch auch alles verschlüsselt?
Zertifikate gestatten uns sicher über das Internet Daten auszutauschen. Alles wird verschlüsselt.
… doch Verschlüsselung ist nur eine von vielen Funktionen von Zertifikaten.
Und hier beginnt die leidige Geschichte, was wann wie sicher und sinnvoll ist.
Zertifikate beinhalten Schlüssel für die Sicherung der Daten, und in vielen Bereichen wäre das schon genug.
Doch jetzt kommen noch andere Punkte hinzu und hier begannen für mich oft die Probleme im Embedded oder IoT Bereich.
-
Bindung an einen bestimmten Namen
Man kann nicht (so leicht) ein Zertifikat auf mehrere Server ausrollen, die unterschiedlichen Domänen angehören. Man müsste für jede Instanz ein eigenes Zertifikat ausstellen, denn der Domain-Name ist im Zertifikat verankert. Schlimmer ist aber die Tatsache, dass Embedded Systeme nicht immer an einen DNS Server angebunden sind. Programme bekommen oft nur eine statische IP konfiguriert, mit der sie kommunizieren sollen. -
Zugehörigkeit zu einem vertrauenswürdigen Aussteller
Das kostet Geld. Jedes offizielle Zertifikat trägt (kryptographisch gesichert) Partikel seines Ausstellers in sich. Das macht es relativ sicher gegen Fälschungen. Doch vertrauenswürdig bedeutet, dass der Client auch wissen muss, welcher Aussteller vertrauenswürdig ist. Jedes OS hat nach der Installation eine Liste der gängigsten Aussteller vorinstalliert. Allerdings müssen regelmäßig Updates eingespielt werden, damit diese Liste auf dem neuesten Stand bleibt und neuere Zertifikate auch bestätigt werden können … also bräuchte man eine Internetleitung … was im Industrie- oder Embedded-Bereich nicht immer möglich ist. -
Limitierung auf einen bestimmten Zeitbereich
Zertifikate haben eine Gültigkeit nach Uhrzeit. Außerhalb dieser Periode werden sie automatisch ungültig. Blöd nur, dass gerade Embedded Systeme nicht immer über die stabilste Uhrzeit verfügen. Da kann es schon mal vorkommen, dass man wieder ins Jahr 2000 zurückspringt. Und dann war’s das mit sicherer Kommunikation.
Lösung:
Man schaltet die Verifizierung der Zertifikate programmatisch ab.
Das ist eine sehr unschöne Vorgehensweise … doch was kann man sonst tun?
Aus meiner Sicht fehlt den Standardimplementierungen von SSL/TLS, eine
“minimale” Datensicherung, die nur einen sicheren Schlüsseltausch und
die eigentliche Verschlüsselung bereitstellt.
Über solche Kanäle können dann Passwörter und sensible Daten übertragen werden,
und somit hätten wir das ganze auch Embedded-tauglich gestaltet.
Doch ohne dieses Feature implementiert wieder jeder was eigenes (auch ich) oder wir erstellen Zertifikate selbst und deaktivieren dann per Programmcode die zusätzlichen Sicherungen.
Tja … dieses Thema ist und bleibt eine Grauzone. Selbst bei größeren Herstellern ist das Deaktivieren der Verifikation etabliert.
Vor einigen Jahren vertrat ich noch etwas radikaler die Meinung, dass Zertifikate ohnehin nur ein Zusatzluxus wären … denn das Internet routet einen ja ohnehin nur dorthin, wo man eben hin möchte. Wozu soll man dann noch per Zertifikat nachprüfen, ob man wirklichen auf dem richtigen Server gelandet ist.
Naja … natürlich könnte ein Hacker den PC bereits übernommen haben und einen bösen DNS Server eingetragen haben. Aber dieses Argument zählt nicht, denn wenn der Hacker schon am Rechner ist, dann kann er ohnehin schon viel zu viel.
Und dann kam ein Beitrag im
Chaos Radio Express, dass einige nicht ganz
so stabile Regierungen absichtlich die zentralen Landes-
Backbones zur
Umleitung des Datenverkehrs gezwungen hatte.
Wer facebook.com eintippte kam unter Umständen auf eine Fake-Seite, die
bereitwillig das Passwort entgegennahm.
Und so etwas lässt sich eben nur mit Zertifikaten bekämpfen. Diese können nicht (so leicht) gefälscht werden und wegen ihres Ablaufdatums ist der Betreiber stets gezwungen neue auszustellen. Falls also jemand so lange rechnet, bis er die Schlüssel rekonstruiert hat, ist schon wieder ein neuer im Umlauf und der alte ungültig.
Natürlich setzt das voraus, dass die User die Warnungen des Browsers nicht ignorieren, wenn dieser feststellt, dass ein Zertifikat nicht zum Server passt, mit dem gerade kommuniziert wird.
Fazit: Mit Zertifikaten ist es
wie mit der Demokratie.
Sie sind die schlechteste Sicherungslösung, abgesehen von allen anderen,
die von Zeit zu Zeit ausprobiert worden sind.