Wie TLS eine sichere Webverbindung herstellt und was der Browser prüft

Wenn Sie eine HTTPS-Seite öffnen, müssen Browser und Server vereinbaren, wie die Kommunikation geschützt wird, bevor sie Anwendungsdaten austauschen. Diese anfängliche Verhandlung wird als TLS-Handshake bezeichnet. Es ist kein vom Benutzer eingegebenes Passwort: Es ist ein automatischer Austausch von Nachrichten und kryptografischen Parametern.

TLS schützt Daten im Transit durch Vertraulichkeit und Integrität und ermöglicht die Authentifizierung des Servers. Das praktische Ergebnis ist ein Kanal, in dem ein Netzwerkbeobachter den Verkehr nicht lesen oder stillschweigend ändern sollte. TLS verschlüsselt nicht von selbst die auf Geräten oder Servern gespeicherten Informationen, noch entscheidet es, ob der Inhalt der Website ehrlich ist.

SSL ist der Name des Vorgängerprotokolls, das heute veraltet ist; in aktuellen Webverbindungen ist das relevante Protokoll TLS. Aus Gewohnheit spricht man noch von "SSL-Zertifikaten", aber das Zertifikat ist eine digitale Berechtigung und TLS ist das Protokoll, das die Verbindung herstellt und schützt. Zertifikat und Protokoll sind unterschiedliche Teile: Die Installation eines davon reicht nicht aus, um zu beweisen, dass die TLS-Konfiguration gut gemacht ist.

Am Anfang sendet der Client eine ClientHello-Nachricht mit Informationen über die unterstützten Optionen, wie TLS-Versionen, Algorithmen und Daten für den Schlüsselaustausch. Der Server antwortet, indem er kompatible Parameter auswählt. Es wird keine willkürliche Kombination gewählt: Beide Enden müssen sich auf die von ihren Implementierungen und Konfigurationen erlaubten Optionen einigen.

In TLS 1.3 kann der Client in der ersten Nachricht einen Teil des öffentlichen Schlüsselaustauschs für ephemere Schlüssel einbeziehen. Der Server wählt die Parameter aus, präsentiert sein Zertifikat und sendet seinen entsprechenden Teil; beide Enden leiten unabhängig gemeinsame Geheimnisse und Verkehrsschlüssel ab. Mit ECDHE —ephemerer Diffie-Hellman über elliptische Kurven— wird der Sitzungsgeheimnisschlüssel nicht als Daten übertragen, die ein Dritter kopieren könnte: Es werden öffentliche Werte ausgetauscht, die es ermöglichen, das Geheimnis auf beiden Seiten zu berechnen.

Symmetrische Verschlüsselung schützt den nachfolgenden Verkehr, da sie für die Verarbeitung großer Datenmengen besser geeignet ist als öffentliche Schlüsseloperationen. TLS leitet Verkehrsschlüssel ab, um die Verbindungsprotokolle zu schützen; es ist nicht ratsam, den Prozess so zu beschreiben, als würde der Browser einfach einen Sitzungsschlüssel erstellen und ihn an den Server übergeben. Das genaue Design hängt von der verhandelten Version und den vereinbarten Parametern ab.

TLS 1.3 reduzierte die gewöhnliche Einrichtung auf eine Netzwerk-Hin-und-Rück-Reise (1-RTT), während TLS 1.2 normalerweise zwei benötigt, bevor der normale Austausch geschützter Daten beginnt. Die Sitzungswiederherstellung mit 0-RTT ist eine andere Option: Sie kann das Senden von Daten vor Abschluss einer neuen Hin-und-Rück-Reise ermöglichen, hat aber Wiederholungsrisiken und ist nicht pauschal für Operationen geeignet, die Duplikate nicht tolerieren. Geringere Latenz bedeutet nicht, dass alle Anfragen für 0-RTT sicher sind.

Das Serverzertifikat verknüpft eine Identität —normalerweise einen Domainnamen— mit einem öffentlichen Schlüssel und enthält eine überprüfbare Signatur innerhalb einer Vertrauenskette. Der Client prüft, dass die Kette zu einer Wurzelautorität führt, die er erkennt, dass das Zertifikat in seiner Gültigkeitsperiode liegt und dass der angeforderte Name mit den vom Zertifikat abgedeckten Namen übereinstimmt, normalerweise im SAN-Feld (Subject Alternative Name).

Die Validierung besteht nicht nur darin, nach einem Schloss zu suchen. Der Browser führt automatische Prüfungen durch und kann die Verbindung ablehnen, wenn das Zertifikat abgelaufen ist, der Name nicht übereinstimmt oder die Kette nicht validiert werden kann. Die Widerrufsprüfung hängt auch von Mechanismen und Richtlinien des Clients ab; man sollte nicht annehmen, dass eine visuelle Inspektion des Symbols alle Details dieses Prozesses offenlegt.

Ein gültiges Zertifikat authentifiziert die Kontrolle über eine Domain gemäß den anwendbaren Ausstellungsregeln; es bescheinigt nicht, dass das Unternehmen legitim ist, dass die Website nicht betrügerisch ist oder dass der Inhalt vertrauenswürdig ist. Eine täuschende Website kann auch HTTPS für ihre eigene Domain bereitstellen. Das Schloss zeigt eine geschützte Verbindung mit diesem Server an, keine Genehmigung seiner Praktiken oder Behauptungen.

Die übliche Web-TLS-Authentifizierung überprüft hauptsächlich den Server. Die gegenseitige Authentifizierung oder mTLS ist eine zusätzliche Konfiguration, bei der der Client auch ein Zertifikat vorlegt, um sich zu authentifizieren. Sie sollte nicht mit dem normalen Betrieb von HTTPS verwechselt werden, bei dem der Benutzer nicht unbedingt ein persönliches Zertifikat vorlegt.

Während einer TLS-Verbindung erschwert die Verschlüsselung es Dritten auf dem Weg, den geschützten Inhalt zu lesen, und die Integrität ermöglicht es, Änderungen der Daten im Transit zu erkennen. Die Serverauthentifizierung hilft, das Risiko zu verringern, dass der Client die Verbindung mit einem Impostor herstellt, der die zertifizierte Identität nicht kontrolliert. Diese Schutzmaßnahmen gelten für den Verbindungsweg, nicht für alle Punkte, durch die die Daten fließen.

TLS verdeckt nicht unbedingt alle Kontextinformationen. Zum Beispiel können die IP-Adresse des Servers und andere Netzwerk-Metadaten weiterhin sichtbar sein; außerdem kann der Servername während der Einrichtung in Konfigurationen, die keine Namensschutzmechanismen verwenden, offengelegt werden. Es verhindert auch nicht, dass die Website selbst, eine bösartige Erweiterung oder ein kompromittiertes Gerät auf die Daten zugreift, sobald sie am Endpunkt entschlüsselt werden.

Eine HTTPS-Verbindung garantiert auch keine Ende-zu-Ende-Verschlüsselung zwischen zwei Personen. Der Server beendet die TLS-Verbindung und kann die empfangenen Daten lesen, um den Dienst bereitzustellen. Verschlüsselter Transport ist nicht gleichbedeutend mit für den Anbieter unzugänglichem Inhalt: Für dieses Ziel ist ein Ende-zu-Ende-Verschlüsselungsdesign erforderlich, bei dem der Dienst die Entschlüsselungsschlüssel nicht kontrolliert.

openssl s_client ermöglicht es, eine TLS-Verbindung zu einem Server zu öffnen und Verhandlungsinformationen zu beobachten, wie das ausgewählte Protokoll, die Chiffresuite und die präsentierten Zertifikate. Für eine Testdomain ist eine grundlegende Überprüfung:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Die Option -servername sendet den Namen über SNI, was erforderlich ist, wenn mehrere Websites dieselbe IP-Adresse teilen. Ohne SNI könnte der Server mit einem Standardzertifikat antworten, das nicht zur zu überprüfenden Domain passt. Ersetzen Sie example.com durch den Namen, den Sie verwalten oder dessen Überprüfung Sie berechtigt sind.

Die Ausgabe ist kein vollständiges Sicherheitsurteil. Untersuchen Sie das verhandelte Protokoll und die Verschlüsselung, die vom Server präsentierte Kette und den Verifizierungscode. Die Verifizierung kann vom Vertrauensspeicher der lokalen OpenSSL-Installation abhängen; ein korrektes Ergebnis auf einem Rechner beweist nicht, wie sich alle Browser oder Geräte verhalten werden.

Um eine bestimmte Verbindung mit TLS 1.3 anzufordern, fügen Sie hinzu, wenn die lokale OpenSSL-Version es zulässt, -tls1_3; für TLS 1.2 verwenden Sie -tls1_2. Diese Optionen dienen der Überprüfung der Kompatibilität mit einer Version, aber eine fehlgeschlagene Verbindung kann auf die Serverrichtlinie, das Netzwerk oder die lokale Implementierung zurückzuführen sein. Ändern Sie die Produktionskonfiguration nicht auf der Grundlage eines einzigen Tests.

Im Browser ermöglicht das Seiteninformationspanel die Überprüfung der Verbindung und der Zertifikatsdaten, obwohl der genaue Pfad vom Browser und seiner Version abhängt. Für eine praktische Überprüfung prüfen Sie mindestens den abgedeckten Namen, den Aussteller, die Gültigkeit und ob die Seite über HTTPS geladen wurde. Entwicklungswerkzeuge können auch Sicherheits- und Anfrageinformationen anzeigen, ersetzen aber keine Überprüfung der Serverkonfiguration.

Handshake-Fehler sind Symptome, keine Diagnosen: Sie können auftreten, wenn Client und Server keine Version oder Chiffresuite teilen, wenn das Zertifikat für den angeforderten Namen ungültig ist, wenn ein Zwischenzertifikat fehlt oder wenn es SNI-Probleme gibt. Eine falsche Uhr kann auch dazu führen, dass ein Zertifikat als noch nicht gültig oder bereits abgelaufen erscheint. Die Ursache zu identifizieren, vermeidet "Reparaturen", die Schutzmaßnahmen entfernen.

In einem Webdienst sollte der Administrator Protokolle und Algorithmen aufrechterhalten, die mit den tatsächlich benötigten Clients kompatibel sind, und veraltete Optionen gemäß seiner Sicherheitsrichtlinie entfernen. TLS 1.3 reduziert geerbte kryptografische Optionen; TLS 1.2 kann für die Kompatibilität noch erforderlich sein, aber seine Sicherheit hängt von der konkreten Parameterauswahl ab. Es reicht nicht aus, eine Version zu aktivieren, ohne den gesamten Konfigurationsatz zu überprüfen.

Eine nützliche Liste für eine erste Überprüfung ist:

• Bestätigen, dass die angeforderte Domain im Zertifikat erscheint und dieses gültig ist.
• Prüfen, ob die erforderliche Zertifikatskette gesendet wird und ob der Server das richtige Zertifikat über SNI verwendet.
• Überprüfen, welche TLS-Version und Chiffresuite mit repräsentativen Clients verhandelt werden.
• Die Serverprotokolle und die OpenSSL-Ausgabe vor der Änderung von Richtlinien untersuchen.
• Vermeiden, die Zertifikatsvalidierung zu deaktivieren oder veraltete Protokolle als schnellen Fix zu reaktivieren.

Deaktivieren Sie die Validierung nicht, um eine Warnung verschwinden zu lassen. Wenn das Problem eine unvollständige Kette, ein falscher Name oder ein abgelaufenes Zertifikat ist, macht das Ignorieren der Prüfung einen sichtbaren Fehler zu einer weniger zuverlässigen Verbindung. Die praktische Entscheidung ist, die Ursache auf dem Server oder Client zu beheben, nicht eine Identität blind zu akzeptieren, die nicht verifiziert werden konnte.