Robert Heaton

HTTPS ist einfach Ihr Standard-HTTP-Protokoll, das mit einer großzügigen Schicht köstlicher SSL/TLS-Verschlüsselung überzogen ist. Wenn nicht gerade etwas furchtbar schief läuft (und das kann es), verhindert es, dass Leute wie die berüchtigte Eve die Anfragen, aus denen sich Ihr Browser-Erlebnis zusammensetzt, einsehen oder ändern können; es sorgt dafür, dass Ihre Kennwörter, Kommunikations- und Kreditkartendaten auf dem Draht zwischen Ihrem Computer und den Servern, an die Sie diese Daten senden wollen, sicher sind. Das kleine grüne Vorhängeschloss und die Buchstaben „https“ in Ihrer Adressleiste bedeuten zwar nicht, dass Sie und die von Ihnen aufgerufene Website nicht noch genügend Möglichkeiten haben, sich anderweitig aufzuhängen, aber sie helfen Ihnen zumindest dabei, sicher zu kommunizieren.

Was ist HTTPS und was bewirkt es?

HTTPS verwendet das bekannte und verständliche HTTP-Protokoll und legt einfach eine SSL/TLS-Verschlüsselungsschicht (im Folgenden einfach „SSL“ genannt) darüber. Server und Clients sprechen immer noch genau das gleiche HTTP miteinander, aber über eine sichere SSL-Verbindung, die ihre Anfragen und Antworten verschlüsselt und entschlüsselt. Die SSL-Schicht hat 2 Hauptzwecke:

• Sicherstellen, dass Sie direkt mit dem Server sprechen, mit dem Sie zu sprechen glauben
• Sicherstellen, dass nur der Server lesen kann, was Sie ihm senden, und nur Sie lesen können, was er zurücksendet

Der wirklich, wirklich clevere Teil ist, dass jeder jede einzelne Nachricht, die Sie mit einem Server austauschen, abfangen kann, einschließlich derjenigen, in denen Sie sich auf den zu verwendenden Schlüssel und die Verschlüsselungsstrategie einigen, und trotzdem nicht in der Lage ist, irgendwelche der tatsächlichen Daten zu lesen, die Sie senden.

Wie eine SSL-Verbindung aufgebaut wird

Eine SSL-Verbindung zwischen einem Client und einem Server wird durch einen Handshake aufgebaut, dessen Ziele sind:

• Den Client davon zu überzeugen, dass er mit dem richtigen Server spricht (und optional umgekehrt)
• Die Parteien müssen sich auf eine „Cipher Suite“ geeinigt haben,
• Die Parteien haben sich auf eine „Cipher Suite“ geeinigt, die den Verschlüsselungsalgorithmus enthält, den sie für den Datenaustausch verwenden werden

Wenn die Verbindung hergestellt ist, können beide Parteien den vereinbarten Algorithmus und die Schlüssel verwenden, um einander sicher Nachrichten zu senden. Wir werden den Handshake in 3 Hauptphasen unterteilen – Hallo, Zertifikatsaustausch und Schlüsselaustausch.

1. Hallo – Der Handshake beginnt damit, dass der Client eine ClientHello-Nachricht sendet. Diese enthält alle Informationen, die der Server benötigt, um sich mit dem Client über SSL zu verbinden, einschließlich der verschiedenen Cipher Suites und der maximalen SSL-Version, die er unterstützt. Der Server antwortet mit einer ServerHello-Nachricht, die ähnliche, vom Client benötigte Informationen enthält, einschließlich einer auf den Präferenzen des Clients basierenden Entscheidung über die zu verwendende Cipher-Suite und SSL-Version.

2. Zertifikatsaustausch – Nachdem der Kontakt hergestellt wurde, muss der Server seine Identität gegenüber dem Client nachweisen. Dies geschieht mit Hilfe seines SSL-Zertifikats, das ein klein wenig wie ein Reisepass ist. Ein SSL-Zertifikat enthält verschiedene Daten, darunter den Namen des Inhabers, die Eigenschaft (z. B. die Domäne), an die es gebunden ist, den öffentlichen Schlüssel des Zertifikats, die digitale Signatur und Informationen über die Gültigkeitsdaten des Zertifikats. Der Client prüft, ob er dem Zertifikat entweder implizit vertraut oder ob es von einer der verschiedenen Zertifizierungsstellen (CAs), denen er ebenfalls implizit vertraut, überprüft wurde und vertrauenswürdig ist. Mehr dazu in Kürze. Beachten Sie, dass der Server auch ein Zertifikat verlangen darf, um die Identität des Clients zu beweisen, aber dies geschieht in der Regel nur in sehr sensiblen Anwendungen.

3. Schlüsselaustausch – Die Verschlüsselung der eigentlichen Nachrichtendaten, die zwischen Client und Server ausgetauscht werden, erfolgt mit einem symmetrischen Algorithmus, dessen genaue Art bereits in der Hello-Phase vereinbart wurde. Ein symmetrischer Algorithmus verwendet einen einzigen Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung, im Gegensatz zu asymmetrischen Algorithmen, die ein öffentliches/privates Schlüsselpaar erfordern. Beide Parteien müssen sich auf diesen einzigen symmetrischen Schlüssel einigen, ein Prozess, der sicher mit asymmetrischer Verschlüsselung und den öffentlichen/privaten Schlüsseln des Servers durchgeführt wird.

Der Client generiert einen Zufallsschlüssel, der für den symmetrischen Hauptalgorithmus verwendet wird. Er verschlüsselt ihn mit einem Algorithmus, der ebenfalls in der Hello-Phase vereinbart wurde, und dem öffentlichen Schlüssel des Servers (zu finden auf dessen SSL-Zertifikat). Er sendet diesen verschlüsselten Schlüssel an den Server, wo er mit dem privaten Schlüssel des Servers entschlüsselt wird, und die interessanten Teile des Handshakes sind abgeschlossen. Die Parteien sind hinreichend sicher, dass sie mit der richtigen Person sprechen und haben sich insgeheim auf einen Schlüssel geeinigt, mit dem sie die Daten, die sie sich gegenseitig schicken wollen, symmetrisch verschlüsseln. HTTP-Anfragen und -Antworten können nun gesendet werden, indem eine Klartextnachricht gebildet, dann verschlüsselt und gesendet wird. Die andere Partei ist die einzige, die weiß, wie diese Nachricht entschlüsselt werden kann, so dass „Man In The Middle“-Angreifer nicht in der Lage sind, abgefangene Anfragen zu lesen oder zu ändern.

Zertifikate

Im Grunde genommen ist ein SSL-Zertifikat einfach eine Textdatei, die jeder mit einem Texteditor erstellen kann. Sie können ganz einfach ein Zertifikat erstellen, das besagt, dass Sie Google Inc. sind und die Domain gmail.com kontrollieren. Wäre dies die ganze Geschichte, dann wäre SSL ein Witz; die Identitätsüberprüfung bestünde im Wesentlichen darin, dass der Client den Server fragt: „Sind Sie Google?“, der Server antwortet: „Äh, ja klar, hier ist ein Stück Papier, auf dem ‚Ich bin Google‘ steht“, und der Client sagt: „OK, toll, hier sind alle meine Daten.“ Der Zauber, der diese Farce verhindert, liegt in der digitalen Signatur, die es einer Partei ermöglicht, zu überprüfen, ob das Stück Papier einer anderen Partei wirklich echt ist.

Es gibt 2 vernünftige Gründe, warum Sie einem Zertifikat vertrauen können:

• Wenn es auf einer Liste von Zertifikaten steht, denen Sie implizit vertrauen
• Wenn es nachweisen kann, dass es vom Inhaber eines der Zertifikate auf der obigen Liste vertrauenswürdig ist

Das erste Kriterium ist leicht zu überprüfen. Ihr Browser verfügt über eine vorinstallierte Liste von vertrauenswürdigen SSL-Zertifikaten von Zertifizierungsstellen (CAs), die Sie anzeigen, hinzufügen und entfernen können. Diese Zertifikate werden von einer zentralisierten Gruppe von (theoretisch und im Allgemeinen in der Praxis) äußerst sicheren, zuverlässigen und vertrauenswürdigen Organisationen wie Symantec, Comodo und GoDaddy kontrolliert. Wenn ein Server ein Zertifikat aus dieser Liste vorlegt, wissen Sie, dass Sie ihm vertrauen können.

Das zweite Kriterium ist viel schwieriger. Es ist leicht für einen Server zu sagen: „Ja, ich heiße Microsoft, du vertraust Symantec und die vertrauen mir, also ist alles in Ordnung.“ Ein halbwegs intelligenter Kunde könnte dann zu Symantec gehen und fragen: „Ich habe hier einen Microsoft, der sagt, dass Sie ihm vertrauen, stimmt das?“ Aber selbst wenn Symantec sagt: „Ja, wir kennen sie, Microsoft ist legitim“, wissen Sie immer noch nicht, ob der Server, der sich als Microsoft ausgibt, tatsächlich Microsoft ist oder etwas viel Schlimmeres. Hier kommen digitale Signaturen ins Spiel.

3.2 Digitale Signaturen

Wie bereits erwähnt, haben SSL-Zertifikate ein zugehöriges öffentliches/privates Schlüsselpaar. Der öffentliche Schlüssel wird als Teil des Zertifikats verteilt, und der private Schlüssel wird unglaublich sicher aufbewahrt. Dieses asymmetrische Schlüsselpaar wird im SSL-Handshake verwendet, um einen weiteren Schlüssel für beide Parteien zur symmetrischen Ver- und Entschlüsselung von Daten auszutauschen. Der Client verwendet den öffentlichen Schlüssel des Servers, um den symmetrischen Schlüssel zu verschlüsseln und ihn sicher an den Server zu senden, und der Server verwendet seinen privaten Schlüssel, um ihn zu entschlüsseln. Jeder kann mit dem öffentlichen Schlüssel verschlüsseln, aber nur der Server kann mit dem privaten Schlüssel entschlüsseln.

Das Gegenteil ist bei einer digitalen Signatur der Fall. Ein Zertifikat kann von einer anderen Behörde „signiert“ werden, wodurch die Behörde effektiv zu Protokoll gibt, dass „wir überprüft haben, dass der Inhaber dieses Zertifikats auch die im Zertifikat aufgeführte Eigenschaft (Domäne) kontrolliert“. In diesem Fall verwendet die Behörde ihren privaten Schlüssel, um (grob gesagt) den Inhalt des Zertifikats zu verschlüsseln, und dieser verschlüsselte Text wird dem Zertifikat als digitale Signatur beigefügt. Jeder kann diese Signatur mit dem öffentlichen Schlüssel der Behörde entschlüsseln und überprüfen, ob sie den erwarteten entschlüsselten Wert ergibt. Aber nur die Zertifizierungsstelle kann Inhalte mit dem privaten Schlüssel verschlüsseln, so dass nur sie überhaupt eine gültige Signatur erstellen kann.

Wenn also ein Server auftaucht, der behauptet, ein Zertifikat für Microsoft.com zu besitzen, das von Symantec (oder einer anderen Zertifizierungsstelle) signiert ist, muss sich Ihr Browser nicht auf dessen Wort verlassen. Wenn das Zertifikat echt ist, hat Symantec seinen (streng geheimen) privaten Schlüssel verwendet, um die digitale Signatur des SSL-Zertifikats des Servers zu erstellen, und Ihr Browser kann seinen (streng öffentlichen) öffentlichen Schlüssel verwenden, um zu prüfen, ob diese Signatur gültig ist. Symantec hat Schritte unternommen, um sicherzustellen, dass die Organisation, für die sie signieren, wirklich Microsoft.com besitzt, und da Ihr Client Symantec vertraut, kann er sicher sein, dass er wirklich mit Microsoft Inc. spricht.

3.3 Selbstsignierung

Beachten Sie, dass alle Root-CA-Zertifikate „selbstsigniert“ sind, was bedeutet, dass die digitale Signatur mit dem eigenen privaten Schlüssel des Zertifikats erzeugt wird. Das Zertifikat einer Stammzertifizierungsstelle ist an sich nichts Besonderes – Sie können Ihr eigenes selbstsigniertes Zertifikat erstellen und dieses zum Signieren anderer Zertifikate verwenden, wenn Sie möchten. Da Ihr zufälliges Zertifikat aber in keinem Browser als CA vorinstalliert ist, wird keiner von ihnen Ihnen vertrauen, dass Sie Ihre eigenen oder andere Zertifikate signieren. Sie sagen also: „Ja, ich bin Microsoft, hier ist ein offizielles Identitätszertifikat, das von mir ausgestellt und signiert wurde“, und alle ordnungsgemäß funktionierenden Browser werden eine sehr beängstigende Fehlermeldung als Antwort auf Ihre fragwürdigen Anmeldeinformationen ausgeben.

Das bedeutet eine enorme Belastung für alle Browser- und Betriebssystemhersteller, nur blitzsauberen Root-Zertifizierungsstellen zu vertrauen, da dies die Organisationen sind, denen ihre Benutzer letztendlich vertrauen, um Websites zu überprüfen und Zertifikate sicher zu halten. Das ist keine leichte Aufgabe.

3.4 Worauf vertrauen Sie?

Es ist interessant festzustellen, dass Ihr Client technisch gesehen nicht versucht zu überprüfen, ob er der Partei, die ihm ein Zertifikat geschickt hat, vertrauen soll oder nicht, sondern ob er dem im Zertifikat enthaltenen öffentlichen Schlüssel vertrauen soll. SSL-Zertifikate sind völlig offen und öffentlich, so dass jeder Angreifer das Zertifikat von Microsoft abfangen, die Anfrage eines Clients an Microsoft.com abfangen und ihm das legitime Zertifikat vorlegen könnte. Der Client würde dies akzeptieren und mit dem Handshake beginnen. Wenn der Client jedoch den Schlüssel verschlüsselt, der für die eigentliche Datenverschlüsselung verwendet wird, verwendet er den echten öffentlichen Schlüssel von Microsoft aus diesem echten Zertifikat. Da der Angreifer nicht im Besitz des privaten Schlüssels von Microsoft ist, um diesen zu entschlüsseln, sitzt er nun fest. Selbst wenn der Handshake abgeschlossen ist, kann er den Schlüssel nicht entschlüsseln und somit auch keine Daten entschlüsseln, die der Client an ihn sendet. Die Ordnung bleibt erhalten, solange der Angreifer nicht den privaten Schlüssel eines vertrauenswürdigen Zertifikats kontrolliert. Wenn der Kunde irgendwie dazu gebracht wird, einem Zertifikat und einem öffentlichen Schlüssel zu vertrauen, dessen privater Schlüssel von einem Angreifer kontrolliert wird, beginnt der Ärger.

4.1 Kann ein Café meinen HTTPS-Verkehr über sein Netzwerk überwachen?

Nein. Die Magie der Public-Key-Kryptographie bedeutet, dass ein Angreifer jedes einzelne Byte der zwischen Ihrem Client und dem Server ausgetauschten Daten beobachten kann und trotzdem keine Ahnung hat, was Sie einander sagen, abgesehen von der ungefähren Datenmenge, die Sie austauschen. Ihr normaler HTTP-Verkehr ist jedoch in einem unsicheren WLAN-Netz immer noch sehr anfällig, und eine unsichere Website kann Opfer einer Reihe von Umgehungsmethoden werden, die Sie dazu bringen, HTTPS-Verkehr entweder über normales HTTP oder an die völlig falsche Stelle zu senden. Selbst wenn beispielsweise ein Anmeldeformular eine Kombination aus Benutzername und Kennwort über HTTPS übermittelt, könnte ein Angreifer, wenn das Formular selbst unsicher über HTTP geladen wird, den HTML-Code des Formulars auf dem Weg zu Ihrem Rechner abfangen und so verändern, dass er die Anmeldedaten an seinen eigenen Endpunkt sendet.

4.2 Kann mein Unternehmen meinen HTTPS-Verkehr über sein Netzwerk überwachen?

Wenn Sie auch einen Rechner verwenden, der von Ihrem Unternehmen kontrolliert wird, dann ja. Denken Sie daran, dass an der Spitze jeder Vertrauenskette eine implizit vertrauenswürdige Zertifizierungsstelle steht und dass eine Liste dieser Stellen in Ihrem Browser gespeichert ist. Ihr Unternehmen könnte seinen Zugriff auf Ihren Computer nutzen, um sein eigenes selbstsigniertes Zertifikat zu dieser Liste von Zertifizierungsstellen hinzuzufügen. Sie könnten dann alle Ihre HTTPS-Anfragen abfangen und Ihnen Zertifikate vorlegen, die angeblich die entsprechende Website repräsentieren, von ihrer gefälschten Zertifizierungsstelle signiert sind und daher von Ihrem Browser ohne Zweifel als vertrauenswürdig eingestuft werden. Da Sie alle Ihre HTTPS-Anfragen mit dem öffentlichen Schlüssel des fragwürdigen Zertifikats verschlüsseln, könnten sie den entsprechenden privaten Schlüssel verwenden, um Ihre Anfrage zu entschlüsseln und zu prüfen (oder sogar zu ändern) und sie dann an den vorgesehenen Ort zu senden. Das tun sie wahrscheinlich nicht. Aber sie könnten.

Zufälligerweise ist dies auch die Art und Weise, wie Sie einen Proxy verwenden, um die ansonsten unzugänglichen HTTPS-Anfragen einer iPhone-App zu inspizieren und zu modifizieren.

4.3 Was ist also mit Lavabit und dem FBI passiert?

Lavabit war Edward Snowdens super-sicherer E-Mail-Anbieter während des NSA-Leaks-Wahnsinns 2013. Wie wir gesehen haben, konnte das FBI mit keinem Standard-Hackerangriff die Daten einsehen, die zwischen Lavabit und seinen Kunden unterwegs waren. Ohne den privaten Schlüssel für das Lavabit-SSL-Zertifikat war die Behörde aufgeschmissen. Ein hilfsbereiter US-Richter sagte dem Lavabit-Gründer Ladar Levison jedoch, dass er diesen Schlüssel aushändigen müsse, und gab dem FBI damit freie Hand, den Datenverkehr nach Herzenslust auszuschnüffeln. Levison unternahm einen tapferen Versuch, die Herausgabe des Schlüssels mit 2.560 Zeichen auf 11 Seiten in 4-Punkt-Schrift hinauszuzögern, wurde aber mit einer Verfügung belegt, die ihn dazu verpflichtete, den Schlüssel in einem brauchbaren Format herauszugeben oder eine Geldstrafe von 5.000 Dollar pro Tag zu zahlen, bis er dies tat.

Nachdem er dem nachgekommen war, widerrief GoDaddy, die Zertifizierungsstelle von Lavabit, das Zertifikat, da sie es (richtigerweise) als gefährdet ansah. Dadurch wurde das Lavabit-Zertifikat in eine Certificate Revocation List (CRL) aufgenommen, eine Liste diskreditierter Zertifikate, denen Kunden nicht mehr vertrauen sollten, um eine sichere Verbindung herzustellen. Kompromittierte, selbstsignierte oder anderweitig nicht vertrauenswürdige Zertifikate führen dazu, dass die Browser eine große rote Fehlermeldung anzeigen und den Benutzer von weiteren Aktionen abhalten oder diese ganz verbieten. Leider vertrauen die Browser einem defekten Zertifikat so lange, bis sie die neuesten Aktualisierungen der CRL abrufen, ein Prozess, der in der Praxis offenbar nicht perfekt ist.

Schlussfolgerung

HTTPS ist nicht unknackbar, und das SSL-Protokoll muss ständig weiterentwickelt werden, wenn neue Angriffe darauf entdeckt und abgewehrt werden. Aber es ist immer noch eine beeindruckend robuste Methode, um geheime Daten zu übermitteln, ohne sich darum zu kümmern, wer Ihre Nachrichten sieht. Es gibt natürlich viele Implementierungsdetails, die hier nicht erwähnt werden, wie z. B. das genaue Format und die Reihenfolge der Handshake-Nachrichten, abgekürzte Handshakes, um die letzten Sitzungen aufzufangen, ohne Schlüssel und Cipher Suites neu aushandeln zu müssen, und die zahlreichen verschiedenen Verschlüsselungsoptionen, die in jeder Phase zur Verfügung stehen. Das Wichtigste ist, dass HTTPS zwar die Daten auf dem Weg zum Zielort sicher hält, Sie (als Benutzer oder Entwickler) aber in keiner Weise vor XSS, Datenbanklecks oder anderen Dingen schützt, die in der Nacht passieren können. Seien Sie froh, dass es Ihnen den Rücken freihält, aber bleiben Sie wachsam. Um es mit den unsterblichen Worten von Will Smith zu sagen: „Gehe im Schatten, bewege dich in der Stille, schütze dich vor außerirdischer Gewalt.“

Wenn Ihnen das gefallen hat, wird Ihnen wahrscheinlich auch mein Beitrag gefallen, in dem ich die Details der FREAK-Schwachstelle in SSL aus dem Jahr 2015 erkläre.