Das kleine Schloss in der Adresszeile des Browsers ist so selbstverständlich geworden, dass kaum jemand darüber nachdenkt. Dahinter steckt TLS (Transport Layer Security), das Protokoll, das fast jede Verbindung im Web verschlüsselt: beim Online-Banking, beim Einkaufen, beim Abrufen von E-Mails und auch beim Lesen dieser Seite. HTTPS ist nichts anderes als HTTP über eine TLS-Verbindung.
Dieser Artikel erklärt, was beim Aufbau einer HTTPS-Verbindung passiert, wie Browser prüfen, ob sie wirklich mit dem richtigen Server sprechen, und was das Schloss bedeutet und was nicht.
Was TLS leistet
TLS sorgt für drei Dinge:
- Vertraulichkeit: Niemand auf dem Weg, etwa im öffentlichen WLAN oder beim Internetanbieter, kann mitlesen.
- Integrität: Niemand kann die Daten unterwegs unbemerkt verändern, etwa Werbung oder Schadcode einschleusen.
- Authentizität: Der Browser kann prüfen, dass er wirklich mit dem Server von techuni.de spricht und nicht mit einem Betrüger, der sich dazwischengeschaltet hat.
Die ersten beiden Punkte erledigen symmetrische Verschlüsselung und Prüfsummen, den dritten erledigen Zertifikate und die Public-Key-Infrastruktur (PKI). Die Grundbegriffe erklärt der Artikel Verschlüsselung für Einsteiger.
Der TLS-Handshake Schritt für Schritt
Bevor die eigentlichen Daten fließen, handeln Browser und Server in einem kurzen Handshake aus, wie sie verschlüsseln. Bei der aktuellen Version TLS 1.3 (seit 2018, RFC 8446) braucht das nur einen einzigen Hin- und Rückweg:
- ClientHello: Der Browser schickt, welche Verfahren er beherrscht, eine Zufallszahl und gleich einen eigenen Schlüsselanteil für den Schlüsselaustausch. Er nennt außerdem den Namen der gewünschten Website (SNI), weil auf einem Server oft viele Websites liegen.
- ServerHello: Der Server wählt die Verfahren aus und schickt seinen eigenen Schlüsselanteil. Aus beiden Anteilen berechnen Browser und Server jetzt unabhängig voneinander denselben geheimen Schlüssel, ohne dass er je übertragen wird. Ab hier ist alles verschlüsselt.
- Zertifikat und Signatur: Der Server schickt sein Zertifikat und signiert den bisherigen Handshake mit seinem privaten Schlüssel. So beweist er, dass er den passenden Schlüssel zum Zertifikat besitzt.
- Finished: Beide Seiten bestätigen mit einer Prüfsumme über den ganzen Handshake, dass nichts manipuliert wurde. Danach fließen die eigentlichen HTTP-Daten.
Der Schlüsselaustausch: Diffie-Hellman
Der Trick, mit dem zwei Parteien über eine abhörbare Leitung ein gemeinsames Geheimnis vereinbaren, heißt Diffie-Hellman-Schlüsselaustausch. Heute wird er fast immer mit elliptischen Kurven gerechnet (ECDHE), meist mit der Kurve X25519. Weil für jede Verbindung neue, flüchtige Schlüssel erzeugt werden, bietet TLS 1.3 immer Forward Secrecy: Selbst wenn jemand später den privaten Schlüssel des Servers stiehlt, kann er früher aufgezeichnete Verbindungen nicht entschlüsseln.
Gegen künftige Quantencomputer kombinieren Chrome, Firefox und viele große Websites den klassischen Austausch inzwischen mit dem Post-Quanten-Verfahren ML-KEM (Hybridverfahren X25519MLKEM768). Mehr dazu im Artikel über Post-Quanten-Kryptographie.
Die Datenverschlüsselung
Die eigentlichen Daten verschlüsselt TLS 1.3 symmetrisch, mit AES-GCM oder ChaCha20-Poly1305. Beide Verfahren verschlüsseln und prüfen gleichzeitig, ob die Daten verändert wurden (authentifizierte Verschlüsselung). Symmetrische Verfahren sind viel schneller als Public-Key-Verfahren wie RSA, die deshalb nur für die Signatur im Handshake eingesetzt werden.
Zertifikate: Woher weiß der Browser, wem er vertraut?
Ein Zertifikat ist eine digital signierte Bescheinigung: „Der öffentliche Schlüssel X gehört zur Domain www.techuni.de.“ Ausgestellt wird es von einer Zertifizierungsstelle (Certificate Authority, CA). Der Browser prüft:
- ob der Domainname im Zertifikat zur aufgerufenen Adresse passt,
- ob das Zertifikat noch gültig und nicht widerrufen ist,
- ob die Signaturkette bis zu einem Wurzelzertifikat reicht, das im Betriebssystem oder Browser als vertrauenswürdig hinterlegt ist.
Dass Zertifikate heute kostenlos und automatisch ausgestellt werden, ist vor allem Let’s Encrypt zu verdanken. Wie das mit dem ACME-Protokoll funktioniert, erklärt der Artikel ACME und Let’s Encrypt. Die Laufzeiten werden dabei immer kürzer: Die Browserhersteller und Zertifizierungsstellen haben 2025 im CA/Browser Forum beschlossen, die maximale Gültigkeit schrittweise zu senken, ab März 2026 auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 47 Tage. Ohne Automatisierung ist das kaum noch zu verwalten.
Was das Schloss bedeutet und was nicht
Das Schloss garantiert, dass die Verbindung zu genau dieser Domain verschlüsselt ist und dass der Server ein gültiges Zertifikat für sie hat. Es sagt nichts darüber, ob die Website seriös ist. Auch Phishing-Seiten haben heute fast immer ein gültiges Zertifikat, oft für eine Adresse, die der echten zum Verwechseln ähnlich sieht (etwa „techuni-login.de“ statt „techuni.de“). Entscheidend ist daher, auf die Domain zu achten, nicht nur auf das Schloss.
Alte Versionen: SSL, TLS 1.0 und 1.1
Der Vorgänger von TLS hieß SSL. Der Name hält sich bis heute („SSL-Zertifikat“), obwohl SSL 3.0 seit 2015 nicht mehr verwendet werden darf (RFC 7568). TLS 1.0 und 1.1 wurden 2021 mit RFC 8996 für veraltet erklärt, alle modernen Browser lehnen sie ab. Aktuell sind TLS 1.2 und TLS 1.3. TLS 1.3 ist schneller, weil es einen Round Trip weniger braucht, und sicherer, weil es veraltete Verfahren gar nicht mehr anbietet.
Fazit
HTTPS schützt Verbindungen mit TLS: Im Handshake vereinbaren Browser und Server per Diffie-Hellman einen gemeinsamen Schlüssel, der Server beweist mit seinem Zertifikat seine Identität, und danach werden alle Daten symmetrisch verschlüsselt und gegen Manipulation gesichert. Das Schloss im Browser zeigt eine sichere Verbindung, aber keine vertrauenswürdige Website. Weitere Artikel finden Sie in der Übersicht Verschlüsselung und IT-Sicherheit.
Quellen und weiterführende Links
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 8996: Deprecating TLS 1.0 and TLS 1.1
- Ballot SC-081: kürzere Zertifikatslaufzeiten (CA/Browser Forum)
- BSI TR-02102: Kryptographische Verfahren (BSI)















Neueste Kommentare