HTTPS-Schwächen. Teil 2

Jedes System hat seine eigenen Stärken und Schwächen. Der erste Teil über HTTPS-Schwächen löste eine zweideutige Reaktion aus, dass „dies keine Schwächen sind, es sollte so sein“. Der erste Teil sagte:

1. Über die Unmöglichkeit, Benutzern vollständige Vertraulichkeit und Privatsphäre zu bieten (Sie können die von einer Person besuchten Ressourcen weiterhin verfolgen und sperren)
2. Die Tatsache, dass Zertifikate über einen offenen Kanal übertragen werden und häufig mehr Informationen als die aktuelle Ressource enthalten (z. B. enthält das bing.com-Zertifikat Informationen zu 72 zusätzlichen Ressourcen, einschließlich Jungfrau, Test, Beta-Umgebung).

Ich werde es weiterhin Design "Schwächen" nennen. In diesem Artikel werden wir über eine weitere Schwäche sprechen - die Zentralisierung .

HTTPS basiert auf SSL- und TLS-Protokollen (der Einfachheit halber werden wir einfach SSL aufrufen - obwohl SSL und TLS auf verschiedenen Ebenen des OSI-Stacks funktionieren). Wenn wir von Schwachstellen sprechen, werden wir daher die Zentralisierung des SSL-Protokolls berücksichtigen.

Theorie

Beginnen Sie mit der Theorie der Verschlüsselungsprotokolle. Das Problem bei der modernen Kryptografie ist nicht die Verschlüsselung selbst, sondern was mit den Schlüsseln zu tun ist: wie man sie sicher speichert, überträgt, erstellt und zerstört.

Die Basis von SSL ist die asymmetrische Verschlüsselung , die durch das Vorhandensein von zwei Schlüsseln bestimmt wird. Wenn einer verschlüsselt ist, kann nur der zweite entschlüsseln und umgekehrt.

Die Hauptfunktion der asymmetrischen Verschlüsselung ist die Authentifizierung , überhaupt keine Verschlüsselung - es ist eine ziemlich ressourcenintensive und teure Operation für diesen Algorithmus. Schnelle und effiziente Verschlüsselung ist das Vorrecht symmetrischer Algorithmen, die sowohl für die Verschlüsselung als auch für die Entschlüsselung denselben Schlüssel verwenden.

Einer der Schlüssel bleibt immer auf einer Seite, um seine Identifizierung zu bestätigen. Er wird als privat bezeichnet . Der öffentliche Schlüssel steht allen zur Verfügung.

Stellen Sie sich vor, es gibt ein Dorf der Zukunft, in dem Boris und Anya leben. In Zukunft sind Schlüssel unterschiedlicher Größe bereits strenger, und die Fähigkeiten des Gehirns stehen in keinem Verhältnis zur Moderne, aber der Ansatz bleibt vermutlich der gleiche.

Boris und Anya wollen die Privatsphäre ihrer Liebeskorrespondenz, daher ist die Hauptsache für sie ein sicherer Informationsaustausch.

Im einfachsten Fall sendet Boris Anna eine Nachricht: "Lass uns reden." Anya generiert zwei Paare asymmetrischer Verschlüsselungsschlüssel - privates Pr1 und öffentliches P1. "Komm schon", sagt Anya, "ich bin Anya, hier ist mein öffentlicher Schlüssel, hier ist der symmetrische Verschlüsselungsalgorithmus, den ich kenne." Boris generiert einen symmetrischen Schlüssel S1 und verschlüsselt ihn mit dem öffentlichen Schlüssel Ani P1 (S1). Jetzt kann selbst Boris S1 nicht mehr entschlüsseln, da nur Anya die Nachricht mit ihrem privaten Schlüssel entschlüsseln kann. Am Ende haben Boris und Ani einen symmetrischen Sitzungsschlüssel, um eine zuverlässige Übertragung von Briefen untereinander zu gewährleisten und Eltern daran zu hindern, ihre Korrespondenz zu lesen.



Ich habe dieses Messaging nicht stark reduziert. Tatsächlich haben wir SSL Handshake mit Einwegauthentifizierung beschrieben [1]. In beide Richtungen generiert Boris sein eigenes Schlüsselpaar und überträgt den öffentlichen Schlüssel an Anya.

Eine wichtige Schlussfolgerung, die wir bereits ziehen können. Von den drei Hauptfunktionen des SSL-Protokolls (Authentifizierung, Verschlüsselung, Integrität) ist die Authentifizierung die wichtigste.

Alles ist in Ordnung, bis ein Postbote erscheint, der vom Leben beleidigt ist, der gierig darauf ist, die Briefe anderer Leute zu lesen, und außerdem klug ist. Zwischen Boris und Anya stellt sich die Frage, wie jetzt garantiert werden kann, dass der Postbote ihre Nachrichten nicht lesen kann. Die Antwort ist auf keinen Fall. Der Postbote kann sein eigenes Schlüsselpaar generieren, Boris seinen Schlüssel "angeblich" von Ani entlarven, zwei verschlüsselte Kanäle organisieren und ruhig Briefe lesen.



Das Dilemma kann nur durch die Anwesenheit eines bestimmten Dritten gelöst werden, der garantieren kann, dass der P1-Schlüssel Ana gehört. Stellen Sie sich vor, im Dorf erscheint ein Dorfrat, der ein Verzeichnis der öffentlichen Schlüssel für die Bewohner führt. Anya kann ihren Pass, ihren öffentlichen Schlüssel P1, mitnehmen und sich registrieren lassen. Boris, wenn er P1 von Ani erhält, kann er zum selben Dorfrat gehen und das Register überprüfen. Wenn der Schlüssel nicht passt, können Sie anfangen, den Postboten zu sündigen und ihn für alles Ernsthafte verantwortlich zu machen, obwohl er in Ablehnung geraten kann. Das Problem wird jedoch noch gelöst.



Natürlich kein Camilpho, Boris schleppte sich jedes Mal in den Dorfrat. Daher kann die gleiche Authentifizierung mit dem Dorfrat selbst durchgeführt werden. Der Dorfrat nennt sich jetzt Certification Authority (CA) und hat sein eigenes Schlüsselpaar, P10 und Pr10. Wenn Anya mit einem Reisepass und ihrem öffentlichen Schlüssel ankommt, stellt CA so etwas wie eine Karte aus, die besagt, dass dies Anya ist. Sie besitzt den öffentlichen Schlüssel P1, einige andere Informationen, bis zur Passnummer und fügt ein weiteres Feld für sie hinzu Signaturen: Nimmt alle Informationen von der Karte, entfernt den Hash von der Karte, verschlüsselt sie mit ihrem privaten Schlüssel und nennt sie eine digitale Signatur. Es wäre möglich, auf einen Hash zu verzichten, aber dann war die Signatur zu groß. Und die Zertifizierungsstelle nennt diese Karte jetzt ein Zertifikat.

Für den Austausch von Liebesbotschaften mit Anya gibt Anya ihm nicht nur ihren Namen und ihren öffentlichen Schlüssel, sondern auch ihr Zertifikat. Boris muss nur einmal zum Dorfrat gehen und sie nach ihrem öffentlichen Schlüssel fragen. Alle Informationen, die dieser Schlüssel entschlüsseln kann, werden von vornherein als vom Dorfrat verschlüsselte Informationen betrachtet. Der Postbote weiß überhaupt nicht, was er tun soll, er ist von einem existenziellen Vakuum bedeckt, er hat nur noch eines übrig - zu versuchen, den privaten Schlüssel des Dorfrats abzuholen, damit das Leben wieder normal wird.



Aber das Leben steht nicht still. Boris hat eine andere Freundin in einem Nachbardorf, dann noch eine. Er muss die Schlüssel anderer Dorfräte zu seinen vertrauenswürdigen hinzufügen und beginnt, sein Register bei den öffentlichen Schlüsseln der Zertifizierungsstellen zu führen. Dann gewinnt es eine nationale und supranationale Skala. Es gibt so viele Organisationen, die Zertifikate signieren, dass sie beginnen, sich zu einer Hierarchie zusammenzuschließen. Es wird eine Root-Zertifizierungsstelle angezeigt, die keine Zertifikate von bloßen Sterblichen, sondern nach Überprüfung Zertifikate von Zwischenzentren (Intermediate Certification Authority) unterzeichnet. Für Boris reicht es jetzt aus, nur die öffentlichen Schlüssel der Stammzertifikate zu speichern. Und von Ani erhält er nicht nur eines ihrer Zertifikate, sondern auch Zertifikate von Zwischenzentren, um sie bis zum Wurzelzentrum weiter zu überprüfen.

Problemfeld

Das System wird komplexer und zentraler , und von diesem Moment an hat der Postbote wieder eine Chance.

Einerseits verfügt Boris zunächst über eine kleine Liste von Root-Zertifizierungsstellen (Windows schreibt während der Installation etwa 50 Root-Zertifizierungsstellen vor). Andererseits fällt es ihm schwer, jedes Mal die gesamte Kette von Zertifizierungszentren zu verfolgen. Höchstwahrscheinlich wird er nicht mehr überprüfen, ob das Zertifikat von Ani aus seinem eigenen Dorf aus irgendeinem Grund das Zertifizierungszentrum eines anderen Landes angibt. Er vertraut seiner Liste der Wurzelzentren mit 99,9 Prozent. Ein Postbote kann den brutalsten Weg einschlagen und irgendwie (Social Engineering, Penetration Hacking) seine gefälschte Root-Zertifizierungsstelle in Boris 'Register registrieren.



PS. Diese Methode zum Hinzufügen eines gefälschten Root-Center-Zertifikats wird sowohl von Pentestern (wie mir) als auch von Angreifern aktiv verwendet. Um Penetrationstests durchzuführen und diesen Ansatz zu verwenden, ist mein Lieblingswerkzeug ZapProxy (kostenlos und Open Source), das ein Root-Center-Zertifikat generiert (es muss manuell installiert werden) und dieses Zertifikat dann im laufenden Betrieb durch ein "ähnliches" ersetzt. Auf diese Weise können Sie den Datenverkehr nicht nur anzeigen, sondern auch stoppen, ändern und weiterleiten. Wenn die Validierung auf Ihrem System auf dem Server nicht dupliziert wird, haben Sie definitiv Probleme.

PPS Das zweite Problem, das in diesem Fall aufgeworfen wurde, betrifft Ani und die Angabe eines unverständlichen Zentrums in ihrem Zertifikat. Anya hat das Geld bezahlt und möchte, dass Boris sie trotzdem erkennt. Dieses Problem wird mit SSL Pinning [3] gelöst, wenn der Anwendung nur ein bestimmtes Zertifikat und bestimmte Zertifizierungsstellen als vertrauenswürdig eingestuft werden können. Dies ist besonders nützlich für Anwendungen mit hohem Risiko. Mit Browsern ist dies komplizierter, für mobile Anwendungen, die mit einem oder zwei Diensten arbeiten, einfacher. Zum Experimentieren habe ich ein gefälschtes Zertifikat auf mein Android-Gerät gesetzt, angegeben, dass der Datenverkehr über ZapProxy geleitet werden soll, das im Netzwerk auf meinem Computer herausragt, und untersucht, wie viele Anwendungen diesen Mechanismus verwenden. Fast niemand, ich konnte mit fast allen gängigen Anwendungen die Substitution des Datenverkehrs beobachten und damit spielen.

Also zurück zu unserem Postboten. Die Regierung konnte seinen Eifer nur würdigen und gab ihm den Status eines Geheimagenten mit höheren Befugnissen. Obwohl die privaten Schlüssel der Root-Zertifizierungsstellen unter sieben Sperren, selbstbrennenden Datenträgern und mehrstufigem Schutz gespeichert sind, reicht möglicherweise nicht aus, dass die Autorität des Postboten mit ihnen verhandelt, um ihm ihren privaten Schlüssel zur Verfügung zu stellen, um im laufenden Betrieb gefälschte gültige Zertifikate zu generieren (obwohl alles möglich ist). Er fand einen einfacheren Weg. Er geht zu seinem eigenen Dorfrat, der in der Hierarchie der Zertifizierungszentren auf der untersten Ebene steht, und drängt oder besticht den Dorfrat, sein Zertifikat als Zertifikat eines Zwischenzertifizierungszentrums zu unterzeichnen. Jetzt kann er den Verkehr nicht nur von Boris hören, sondern grundsätzlich von jedem Thema. Die Person wird höchstwahrscheinlich nicht einmal etwas bemerken, der Browser wird keine Warnungen ausgeben.



Dies ist ein bekanntes Problem, und die Menschheit versucht auch, es zu bekämpfen. Wenn solche gefälschten Zertifikate, gefährdeten Zwischen- und Stammzentren gefunden werden, sollten diese Zertifikate als widerrufen und kompromittiert markiert werden (widerrufene Zertifikate). Dies bedeutet, dass Boris diese nicht nur Stammzertifikate speichern muss, sondern sie auch mit der Online-Liste der gesperrten Zertifikate synchronisieren muss. Dieser Mechanismus wird über die Protokolle CRL (Certificate Revocation List) und Online Certificate Status Protocol (OCSP) [4] implementiert, die übrigens funktionieren ungeschützter Kanal. Als wir anfingen, aktiv an der Steuerung des OUTPUT-Verkehrs mit Dhound [5] zu arbeiten, bemerkten wir regelmäßige Anfragen an Port 80. Wenn Sie solche Anforderungen auf Firewall-Ebene verbieten, funktionieren einige Funktionen nicht mehr, z. B. das Senden von E-Mails. Das Problem mit widerrufenen Zertifikaten besteht darin, dass es bereits eine große Anzahl von Zertifikaten gibt: 2013 gab es etwa 3 Millionen widerrufene Zertifikate [6], allein im Jahr 2018 23.000 widerrufene Symantec-Zertifikate [7]. Chrome hat vor einigen Jahren die Standardfunktion der vollständigen Überprüfung widerrufener Zertifikate deaktiviert [8], um die Geschwindigkeit beim Laden von Seiten zu erhöhen. Es stellt sich heraus, dass der Prozess der weiteren Verhinderung seiner Aktionen langwierig und nicht immer erfolgreich sein wird, wenn unser Postbote entdeckt wird.

Schlussfolgerungen

Das moderne SSL-System ist teilweise geschlossen und zentralisiert , was definitiv eine seiner Schwächen ist. Solange dies der Fall ist, wird es für die „mächtigen Menschen dieser Welt“ immer eine Versuchung geben, ihre Vorteile daraus zu ziehen, ohne dass die Privatsphäre Vorrang hat. Dennoch werden auf nationaler Ebene eigene Verschlüsselungsalgorithmen erstellt, um andere Länder von ihren eigenen Bürgern zu isolieren und dies selbst zu tun. Kompromisse bei Schlüsselknoten können das gesamte System zum Erliegen bringen. Die zunehmende Entropie und Komplexität des Systems wird zunehmend zu seinem instabilen Zustand und letztendlich zum Tod des Systems führen.

Welcher Ausweg? Der Übergang von einem geschlossenen und zentralisierten SSL-System zu einem transparenteren und verteilten System, das seiner Natur nach keiner der Parteien Vorteile bringen kann. Vielleicht ist dies eine Lösung, die derjenigen ähnelt, die eine offene Blockchain implementiert.

PS. Das SSL-Protokoll weist komplexere Nuancen auf, die im Artikel nicht erwähnt wurden. Der Informationsstand reichte jedoch aus, um eine seiner Schwächen aufzudecken. Gibt es noch andere Schwächen? In den folgenden Artikeln werden wir schauen.


Gepostet von Denis Koloshko, CISSP