Mit Google fortfahren
TLS verstehen: Handshake, Zertifikate und Schutz
Transport Layer Security (TLS) schützt Daten auf ihrem Weg zwischen zwei Kommunikationspartnern. Dazu verbindet TLS drei Aufgaben: Es verschlüsselt die Übertragung, erkennt Veränderungen und prüft meist mithilfe eines Zertifikats die Identität des Servers.
Auf dieser Seite lernst du, wie diese Schutzkette funktioniert, wie Zertifikate Man-in-the-Middle-Angriffe erschweren und wo die Grenzen von TLS liegen.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Welche Schutzziele erfüllt TLS?
Stell dir eine Anmeldung auf einer Website vor. Ohne Schutz könnten Dritte das Passwort mitlesen, Daten verändern oder sich als der gewünschte Server ausgeben. TLS wirkt diesen Gefahren mit drei Schutzzielen entgegen.
Vertraulichkeit
Nur die vorgesehenen Kommunikationspartner sollen die übertragenen Daten lesen können. TLS erreicht das durch Verschlüsselung.
Integrität
Unbemerkte Veränderungen während der Übertragung sollen erkannt werden. Geschützte Prüfwerte zeigen, ob eine Nachricht manipuliert wurde.
Authentifizierung
Eine Seite weist ihre Identität kryptografisch nach. Bei HTTPS authentifiziert sich normalerweise der Server mit einem Zertifikat. Bei mutual TLS (mTLS) weist auch der Client seine Identität mit einem Zertifikat nach.
Die Schutzziele ergänzen sich. Eine verschlüsselte Verbindung zu einem Angreifer wäre zwar vertraulich gegenüber anderen Beobachtern, aber mit der falschen Gegenstelle aufgebaut. Deshalb genügt Verschlüsselung allein nicht.
Du sendest ein Passwort an einen Webserver:
- Verschlüsselung verhindert das einfache Mitlesen.
- Integritätsschutz macht eine Veränderung der übertragenen Nachricht erkennbar.
- Die Zertifikatsprüfung hilft festzustellen, ob du tatsächlich mit dem vorgesehenen Server verbunden bist.
Erst die Kombination bildet die beabsichtigte Schutzkette.
Wie entsteht beim Handshake ein gemeinsamer Schlüssel?
Bevor Anwendungsdaten fließen, führen Client und Server den TLS-Handshake aus. Dabei einigen sie sich auf eine TLS-Version und geeignete kryptografische Verfahren. Der Server weist außerdem seine Identität nach.
Ein vereinfachter regulärer TLS-1.3-Handshake läuft so ab:
- Der Client sendet unterstützte Parameter, einen Zufallswert und einen Wert für den flüchtigen Schlüsselaustausch.
- Der Server wählt passende Parameter und sendet seinen eigenen Austauschwert.
- Der Server übermittelt sein Zertifikat und beweist mit einer digitalen Signatur, dass er den zugehörigen privaten Schlüssel besitzt.
- Beide Seiten berechnen unabhängig dasselbe gemeinsame Geheimnis und leiten daraus Sitzungsschlüssel ab.
- Sie bestätigen den erfolgreichen Handshake und übertragen anschließend geschützte Anwendungsdaten.
Der Sitzungsschlüssel wird also nicht einfach als lesbarer Schlüssel durch das Netz geschickt. Moderne TLS-1.3-Verbindungen verwenden einen flüchtigen Diffie-Hellman-basierten Schlüsselaustausch wie DHE oder ECDHE.
Forward Secrecy
Für jede Verbindung entsteht neues, flüchtiges Schlüsselmaterial. Wird der langfristige private Schlüssel des Servers später gestohlen, lassen sich frühere aufgezeichnete Sitzungen dadurch nicht automatisch entschlüsseln.
Warum kombiniert TLS verschiedene Verfahren? Public-Key-Verfahren, Signaturen und Diffie-Hellman helfen bei Authentifizierung und Schlüsselaushandlung. Für den großen Datenstrom ist symmetrische Verschlüsselung mit einem gemeinsamen Sitzungsschlüssel schneller.
Der Handshake schafft Vertrauen und Schlüsselmaterial. Danach schützt schnelle symmetrische Kryptografie die Nutzdaten.
Wähle in jeder Lücke die passende Form und prüfe anschließend deine Antworten.
Im werden Parameter und Schlüsselmaterial ausgehandelt. Danach schützt ein Sitzungsschlüssel die Nutzdaten. Neues flüchtiges Schlüsselmaterial ermöglicht .
Wie verhindert ein Zertifikat einen falschen Server?
Ein digitales Zertifikat verbindet eine Serveridentität mit einem öffentlichen Schlüssel. Es wird von einer Zertifizierungsstelle, kurz CA, ausgestellt beziehungsweise bestätigt.
Der Client prüft unter anderem:
- Passt der aufgerufene Servername zum Zertifikat?
- Ist das Zertifikat innerhalb seiner Gültigkeitsdauer?
- Führt die Zertifikatskette zu einer vertrauenswürdigen CA?
- Ist die Zertifikatskette kryptografisch gültig?
- Beweist der Server den Besitz des passenden privaten Schlüssels?
Man-in-the-Middle-Angriff
Ein Angreifer schaltet sich zwischen Client und Server. Er versucht, beiden Seiten jeweils eine eigene Verbindung vorzuspielen, um Daten mitzulesen oder zu verändern.
Ohne zuverlässige Authentifizierung könnte ein solcher Angreifer eigene Schlüssel unterschieben. Eine erfolgreiche Zertifikatsprüfung bindet den verwendeten öffentlichen Schlüssel an den erwarteten Servernamen und erschwert dieses Täuschungsmanöver.
Du rufst eine Website auf, aber ein Angreifer lenkt die Verbindung zu seinem Server um. Sein Server kann zwar irgendein Zertifikat vorlegen. Passt dessen Name nicht zur aufgerufenen Domain oder führt seine Kette nicht zu einer vertrauten CA, muss der Browser warnen oder die Verbindung abbrechen.
Ignorierst du eine solche Warnung, schwächst du die Schutzwirkung der Authentifizierung.
Was geschieht nach dem Handshake?
Nach dem Handshake übernimmt das TLS Record Protocol. Es zerlegt Anwendungsdaten in Datensätze, schützt sie mit den ausgehandelten symmetrischen Schlüsseln und setzt sie beim Empfänger wieder zusammen. TLS muss den Inhalt der Anwendungsdaten dabei nicht verstehen.
Darum kann TLS unterschiedliche höhere Protokolle schützen. Das bekannteste Beispiel ist HTTPS, also HTTP über TLS. Auch E-Mail-, Dateiübertragungs-, Datenbank- und VPN-Verbindungen können TLS einsetzen.
Beim Absenden eines Webformulars verarbeitet die Website weiterhin normale Formulardaten. TLS schützt den Transport zwischen Browser und Webserver. Die Anwendung muss nicht jedes Formularfeld mit einem eigenen Netzwerkverfahren verschlüsseln.
Warnungen und schwere Fehler werden über TLS-Meldungen übertragen. Eine ordnungsgemäße Beendigung kann mit close_notify angekündigt werden. Bei einem schweren Fehler wird die Verbindung beendet, statt unsicher fortzufahren.
Was schützt TLS nicht?
HTTPS bedeutet, dass HTTP über TLS übertragen wird. Ein Browser-Schloss zeigt daher eine geschützte Verbindung an. Es ist aber kein allgemeines Gütesiegel für die Inhalte oder die Absichten des Betreibers.
Auch eine Phishing-Seite kann ein gültiges Zertifikat für ihre eigene Domain besitzen. TLS schützt dann die Verbindung zur Phishing-Seite korrekt, macht die Seite aber nicht vertrauenswürdig.
TLS schützt außerdem jeweils einen Transportabschnitt zwischen zwei Stationen. Werden Daten an einem Endpunkt oder einer Zwischenstation entschlüsselt, können sie dort gelesen, gespeichert oder verändert werden. TLS schützt nicht automatisch vor unsicherer Software, gestohlenen Zugangsdaten oder einer bösartigen Gegenstelle.
TLS beantwortet: „Ist diese Verbindung geschützt und mit welcher Gegenstelle wurde sie aufgebaut?“ Es beantwortet nicht automatisch: „Ist der Betreiber ehrlich und ist das Endgerät sicher?“
Typische technische Schwächen
Ältere Versionen, schwache Verfahren, fehlerhafte Implementierungen und falsche Konfigurationen können die vorgesehene Sicherheit untergraben. Historische Beispiele sind BEAST gegen TLS 1.0, POODLE gegen SSL 3.0, Export-Downgrades wie FREAK und Logjam sowie der Heartbleed-Fehler in OpenSSL.
Kompression kann ebenfalls Informationen verraten: Wenn ein Angreifer Teile des Klartexts beeinflusst und anschließend Länge oder Antwortzeit beobachtet, können Rückschlüsse auf Geheimnisse möglich werden. TLS 1.3 unterstützt deshalb keine TLS-Nutzdatenkompression. Anwendungskompression kann jedoch weiterhin eigene Risiken erzeugen.
Praktische Schutzentscheidungen sind daher:
- aktuelle TLS-Versionen und Implementierungen verwenden;
- veraltete Versionen und schwache Verfahren deaktivieren;
- Zertifikatswarnungen nicht umgehen;
- Software regelmäßig aktualisieren;
- Endpunkte und Anwendungen zusätzlich absichern.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- TLS
- schützt Vertraulichkeit, Integrität und Authentifizierung
- handelt im Handshake Parameter und Schlüsselmaterial aus
- nutzt Zertifikate zur Serverauthentifizierung
- schützt Nutzdaten mit symmetrischen Sitzungsschlüsseln
- ermöglicht mit flüchtigen Schlüsseln Forward Secrecy
- sichert Verbindungen, aber nicht automatisch Endpunkte oder Betreiberabsichten
Abschluss-Check
Du hast das Ziel erreicht, wenn du die TLS-Schutzkette erklären und zugleich begründen kannst, warum eine verschlüsselte Verbindung nicht automatisch eine vertrauenswürdige Website bedeutet.