Dieser Artikel ist Teil 3 von drei meiner Serie über SSL/TLS-Verschlüsselung. Teil 1 behandelt die Grundlagen bekannter Verschlüsselungskonzepte. Teil 2 gibt eine kurze Einführung in OpenSSL und PKI. Dieser Teil geht auf das Problem der PKI-Schwäche ein und stellt zwei Gegenmaßnahmen vor.
Zunächst möchte ich den Begriff relying party einführen . Eine vertrauende Seite ist ein Webbrowser, E-Mail-Client, eine Chat-Anwendung usw., die versucht, ein x.509-Zertifikat zu validieren. Meistens erreicht dies die vertrauende Seite, indem sie überprüft, ob eine Zertifizierungsstelle in ihren Vertrauensankern das Zertifikat signiert hat.
[Das könnte Ihnen auch gefallen: So verwalten Sie mehrere SSH-Schlüsselpaare]
Exkursion:Schützen Sie Ihren privaten Schlüssel
Wie Sie vielleicht aus Teil 1 wissen, müssen Sie den privaten Schlüssel schützen. Dies beginnt bereits bei der Erstellung, die auf einer vertrauenswürdigen Maschine erfolgen sollte.
Jetzt könnten Sie fragen:"Was ist eine vertrauenswürdige Maschine?"
Nun, ein Online-Dienst, der von jemandem betrieben wird, den Sie nicht kennen, ist sicherlich nicht vertrauenswürdig. Sie dürfen Ihren privaten Schlüssel niemals mit einem Webdienst in Ihrem Browser erstellen, da Sie einfach nicht wissen, ob der Dienstanbieter eine Kopie des erstellten Schlüssels aufbewahrt. Um dies zu verhindern, könnten Sie stattdessen einen Offline-Rechner verwenden.
Speichern Sie Ihren privaten Schlüssel nur dort, wo Sie ihn benötigen, und bewahren Sie ihn sicher auf. Ein Verzeichnis auf einem anonymen FTP-Server ist sicherlich kein sicherer Ort. Eine Netzwerkfreigabe, auf die nur privilegierte Benutzer Zugriff haben, oder ein Passwort-Manager, der das Speichern von Anhängen ermöglicht, ist sicherlich ein besserer Ort dafür.
Falls Sie Ihren ungeschützten privaten Schlüssel versehentlich auf eine Netzwerkfreigabe oder ein öffentliches Git-Repo kopiert haben, löschen Sie ihn einfach und erstellen Sie einen neuen. Sie können nicht sicher sein, dass es nicht kompromittiert wurde. Selbst wenn Sie es sofort löschen, können Sie nicht sicher sein, dass es nicht bereits von einem Snapshot-Mechanismus gespeichert wurde.
PKI-Schwächen
Was PKI ist und wie sie funktioniert, wurde in Teil 2 dieser Reihe besprochen. Falls Sie es nicht wissen, lesen Sie zuerst diesen Teil.
Kurz gesagt, der ganze Grund, warum wir uns mit diesem Zertifikatschaos befassen, ist, dass wir der vertrauenden Seite helfen wollen, sicherzustellen, dass sie mit dem richtigen Server kommuniziert und nicht mit einem Betrug. Wir bekommen also ein Zertifikat, das von einer Zertifizierungsstelle signiert ist, der die vertrauende Seite vertraut, und wir sind alle glücklich, richtig?
Nun, das könnten wir sein, wenn PKI nicht einen schwerwiegenden Designfehler hätte.
Es gibt mehrere hundert Zertifizierungsstellen im Internet, denen unsere vertrauende Seite vertraut. Einige dieser CAs haben sogar Sub-CAs, die Zertifikate signieren können und das Vertrauen der vertrauenden Seite haben. Und alle diese Zertifizierungsstellen können ein Zertifikat für jeden gültigen Domänennamen ausstellen.
Im Allgemeinen könnte also jede Zertifizierungsstelle ein Zertifikat für Ihre Domäne ausstellen, ohne dass Sie davon etwas mitbekommen. Dieses Zertifikat könnte für Man-in-the-Middle-Angriffe auf Ihre Domäne verwendet werden, da die vertrauende Seite diesem Zertifikat vertrauen würde, da es von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.
Und das ist keine theoretische Drohung. Im März 2015 wurden einige nicht autorisierte Zertifikate, die von CNNIC ausgestellt wurden, verwendet, um Datenverkehr zu entschlüsseln, der durch die Great Firewall geleitet wird. Im Jahr 2012 gab ein Sicherheitsunternehmen zu, mindestens ein Zertifikat an ein privates Unternehmen ausgegeben zu haben, das damit seine Mitarbeiter ausspionierte. Und im Jahr 2011 erlebte eine Zertifizierungsstelle einen verheerenden Hack, bei dem einige ihrer Signaturzertifikate gestohlen wurden.
Mögliche Gegenmaßnahmen
Die drei obigen Beispiele zeigen Ihnen, was an PKI im Kern falsch läuft. Das Design ist fehlerhaft. Wie kann man es also beheben? Im Folgenden sind zwei Techniken aufgeführt, mit denen das Problem behoben werden kann.
Certificate Authority Authorization (CAA)
Aus der Zusammenfassung des DNS-Ressourceneintrags für die Zertifizierungsstellenautorisierung (CAA) in RFC 8659:„Der DNS-Ressourceneintrag für die Zertifizierungsstellenautorisierung (CAA) ermöglicht es einem Inhaber eines DNS-Domänennamens, eine oder mehrere Zertifizierungsstellen (CAs) anzugeben, die berechtigt sind, Zertifikate dafür auszustellen Domänenname. CAA-Ressourceneinträge ermöglichen es einer öffentlichen CA, zusätzliche Kontrollen zu implementieren, um das Risiko einer unbeabsichtigten Falschausstellung von Zertifikaten zu verringern."
Tja, besser hätte ich es nicht erklären können. CAA ermöglicht Inhabern von Domainnamen festzulegen, welche CAs berechtigt sind, Zertifikate für unsere Domain auszustellen, und die CAs selbst versprechen uns, unsere CAA-Aufzeichnungen zu respektieren. Der RFC 8659 definiert die folgenden drei Eigenschaften:
- issue enthält als Wert die Domain der CA, die durch den CAA-Record berechtigt ist, Zertifikate für eine bestimmte Domain auszustellen.
- issuewild ist im Grunde dasselbe wie issue, jedoch für Wildcard-Zertifikate. Wenn kein issuewild gesetzt ist, wird stattdessen der Wert aus issue verwendet.
- iodef enthält Kontaktinformationen, die verwendet werden können, falls es Probleme mit der CAA-Richtlinie gibt.
Sehen wir uns die folgenden Beispieldatensätze an:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" Die erste Zeile aus dem obigen Beispiel bedeutet, dass nur die Zertifizierungsstelle Let's Encrypt berechtigt wäre, Zertifikate für jeden Host unter der Domäne example.com auszustellen. Andere CA DÜRFEN KEINE Zertifikate für diese Domain ausstellen. Die zweite Zeile gibt Ihnen eine E-Mail-Adresse, an die Sie sich bei Problemen wenden können.
Da DNS hierarchisch organisiert ist, gilt der obige CAA-Record sowohl für web.example.com als auch für host.web.example.com und host.sub.web.example.com. Sehen wir uns ein weiteres Beispiel an:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Hier darf nur die CA example-pki.org Zertifikate für z. B. host.sub.web.example.com ausstellen. Der Eintrag in der dritten Zeile überschreibt die Richtlinie von example.com. Ich denke, du hast die Idee.
Natürlich würden CAA-Ressourceneinträge nicht konforme CAs nicht daran hindern, Zertifikate für Domänen auszustellen, für die sie keine Berechtigung haben. Sie würden jedoch riskieren, aus eingebetteten Vertrauensankern entfernt zu werden, was in den meisten Fällen bedeuten würde, dass sie ihr Geschäft aufgeben würden.
Und es besteht immer noch die Möglichkeit, dass eine autorisierte Zertifizierungsstelle ein Zertifikat fälschlicherweise an jemanden ausstellt, der nicht berechtigt ist, es zu verwenden. Wählen Sie eine Zertifizierungsstelle Ihres Vertrauens und wählen Sie mit Bedacht aus.
Wie Sie sehen, bietet CAA keine 100 %ige Sicherheit, aber es ist einfach zu implementieren und mindert das Risiko einer falschen Ausstellung von Zertifikaten.
Zertifikatstransparenz (CT)
Certificate Transparency ist "... ein experimentelles Protokoll zur öffentlichen Protokollierung der Existenz von Transport Layer Security (TLS)-Zertifikaten, während sie ausgestellt oder beobachtet werden, auf eine Weise, die es jedem ermöglicht, die Aktivität der Zertifizierungsstelle (CA) zu prüfen und die Ausstellung verdächtiger Zertifikate zu bemerken Zertifikate sowie die Zertifikatsprotokolle selbst zu prüfen. Die Absicht ist, dass Clients sich schließlich weigern würden, Zertifikate anzuerkennen, die nicht in einem Protokoll erscheinen, wodurch Zertifizierungsstellen effektiv gezwungen werden, alle ausgestellten Zertifikate zu den Protokollen hinzuzufügen. (Zusammenfassung RFC 6962)
CT bietet eine Form der Abrechnung von TLS-Zertifikaten und ermöglicht Ihnen zu prüfen, welche CA-Zertifikate für Ihre Domainnamen ausgestellt wurden. Dazu können Sie Dienste wie Cert Spotter von sslmate verwenden, das auch als On-Premises-Version verfügbar ist. Früher habe ich die lokale Version auf meinem Virtual Private Server ausgeführt, aber aufgrund des Protokollwachstums in den letzten zwei Jahren scheint es unmöglich, die Protokolle von Anfang bis Ende zu crawlen. Der Job lief wochenlang und wurde nicht beendet; Es wurde abgebrochen, als ich meinen Host neu starten musste, um die Aktualisierungen abzuschließen.
Heutzutage ist keine Zertifizierungsstelle gezwungen, ausgestellte Zertifikate zu CT-Protokollen hinzuzufügen, aber das Protokollwachstum deutet darauf hin, dass viele von ihnen ihre Zertifikate bereits hinzufügen. Meiner Meinung nach ist es nur eine Frage der Zeit, bis große Browser anfangen, Zertifikaten nur noch mit einem CT-Log-Eintrag zu vertrauen und sie obligatorisch zu machen.
[ Holen Sie sich dieses kostenlose E-Book:Verwalten Ihrer Kubernetes-Cluster für Dummies. ]
Abschluss
Das ursprüngliche Design der PKI ist fehlerhaft und nicht mehr sehr vertrauenswürdig. Mit RFC 8659 und RFC 6962 werden zwei Methoden angeboten, um das Vertrauen zurückzugewinnen und Inhabern von Domainnamen dabei zu helfen, den Überblick darüber zu behalten, wer Zertifikate für ihre Domains ausgestellt hat.
Denken Sie also von nun an daran, Ihre privaten Schlüssel zu schützen, CAA-Ressourceneinträge für Ihre Domänen festzulegen und mit der Überwachung von CT-Protokollen zu beginnen.