Wie HTTPS und TLS wirklich funktionieren: Eine Schritt-für-Schritt-Anleitung

Sie haben wahrscheinlich schon das Schloss-Symbol in Ihrem Browser gesehen und angenommen, dass Ihre Verbindung sicher ist. Aber was passiert eigentlich, wenn Sie eine HTTPS-Website besuchen? Woher weiß Ihr Browser, dass er mit dem echten Server und nicht mit einem Betrüger spricht? Und warum verlangsamt TLS manchmal Ihre Website?

In diesem Leitfaden entmystifizieren wir HTTPS und TLS, indem wir den Handshake Schritt für Schritt durchgehen. Sie lernen die Rollen von Zertifikaten, symmetrischer und asymmetrischer Verschlüsselung kennen und wie Sie TLS in Ihren eigenen Projekten überprüfen und optimieren können.

Was HTTPS und TLS tatsächlich tun

HTTPS ist HTTP, das auf TLS (Transport Layer Security) aufsetzt. TLS bietet drei Garantien:

• Vertraulichkeit: Daten werden verschlüsselt, sodass Lauscher sie nicht lesen können.
• Integrität: Daten können während der Übertragung nicht unbemerkt verändert werden.
• Authentifizierung: Sie sprechen mit dem legitimen Server, nicht mit einem Angreifer.

Ohne TLS wird HTTP-Verkehr im Klartext gesendet. Jeder auf dem Netzwerkpfad (WLAN-Hotspots, ISPs, kompromittierte Router) kann ihn lesen oder verändern. TLS löst dies, indem es einen sicheren Kanal einrichtet, bevor HTTP-Daten ausgetauscht werden.

Der TLS-Handshake: Schritt für Schritt

Der Handshake ist, wo die Magie passiert. Es ist eine Verhandlung, die gemeinsame Schlüssel etabliert und Identitäten überprüft. Hier ist der vereinfachte Ablauf für TLS 1.2 und 1.3 (die beiden Versionen, die Ihnen heute begegnen werden).

Schritt 1: Client Hello

Der Client (Browser) sendet eine ClientHello-Nachricht mit:

• Unterstützte TLS-Versionen (z. B. TLS 1.3, TLS 1.2)
• Unterstützte Cipher Suites (Kombinationen von Algorithmen)
• Eine zufällige Byte-Zeichenkette (Client Random)
• Für TLS 1.3: einen Key Share für den Diffie-Hellman-Austausch

Schritt 2: Server Hello und Zertifikat

Der Server antwortet mit einem ServerHello (gewählte Version, Cipher Suite, Server Random) und seinem Zertifikat. Das Zertifikat enthält den öffentlichen Schlüssel des Servers und ist von einer Zertifizierungsstelle (CA) signiert.

Der Client überprüft das Zertifikat: Ist es abgelaufen? Ist es von einer vertrauenswürdigen CA ausgestellt? Stimmt die Domain überein? Wenn nicht, zeigt der Browser eine Warnung an.

Schritt 3: Schlüsselaustausch

Mit dem öffentlichen Schlüssel des Servers (oder Diffie-Hellman-Parametern) leiten Client und Server ein gemeinsames Pre-Master Secret ab. In TLS 1.3 geschieht dies mit ephemerem Diffie-Hellman (ECDHE), was Forward Secrecy bietet: Selbst wenn der private Schlüssel des Servers später kompromittiert wird, bleiben vergangene Sitzungen sicher.

Schritt 4: Finished

Beide Seiten senden eine Finished-Nachricht, verschlüsselt mit den neu abgeleiteten Schlüsseln. Wenn die Entschlüsselung erfolgreich ist, ist der Handshake abgeschlossen. Von da an werden alle Anwendungsdaten (HTTP) mit symmetrischer Verschlüsselung (z. B. AES-GCM oder ChaCha20-Poly1305) verschlüsselt.

TLS 1.3 Verbesserungen

TLS 1.3 reduziert den Handshake auf einen Round Trip (1-RTT) und unterstützt 0-RTT-Wiederaufnahme für wiederkehrende Besucher. Es entfernt auch veraltete Algorithmen, was es schneller und sicherer macht. Die meisten modernen Browser und Server unterstützen TLS 1.3.

Symmetrische vs. asymmetrische Verschlüsselung in TLS

TLS verwendet beide Verschlüsselungsarten aus gutem Grund:

• Asymmetrische (Public-Key-)Verschlüsselung: Wird während des Handshakes verwendet, um den Server zu authentifizieren und Schlüssel sicher auszutauschen. Sie ist rechenintensiv, löst aber das Problem der Schlüsselverteilung.
• Symmetrische Verschlüsselung: Wird für die Massendatenübertragung nach dem Handshake verwendet. Sie ist schnell und effizient.

Dieser hybride Ansatz bietet Ihnen die Sicherheit der Public-Key-Kryptographie mit der Leistung symmetrischer Cipher.

Zertifikate: Vertrauensanker

Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Domainnamen und ist von einer CA signiert. Browser und Betriebssysteme werden mit einem Speicher vertrauenswürdiger Root-CAs ausgeliefert. Wenn ein Server sein Zertifikat präsentiert, baut der Client eine Vertrauenskette bis zu einem vertrauenswürdigen Root auf.

Zertifikate haben eine begrenzte Lebensdauer (heute oft 90 Tage bei Let's Encrypt). Abgelaufene Zertifikate verursachen Browserfehler, daher sollten Sie die Erneuerung automatisieren.

Praktisch: TLS mit OpenSSL inspizieren

Sie können die TLS-Konfiguration eines Servers mit dem Kommandozeilen-Tool openssl inspizieren. Dies hilft beim Debuggen von Handshake-Fehlern oder beim Überprüfen von Cipher Suites.

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

Dies verbindet sich mit dem Server und gibt die Zertifikatskette, die ausgehandelte Cipher und Sitzungsdetails aus. Suchen Sie nach Verify return code: 0 (ok), um zu bestätigen, dass das Zertifikat gültig ist.

Um den Ablauf des Zertifikats zu überprüfen:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Häufige TLS-Fallstricke und wie man sie vermeidet

• Abgelaufene Zertifikate: Richten Sie automatische Erneuerung und Überwachung ein. Verwenden Sie Tools wie Certbot für Let's Encrypt.
• Gemischte Inhalte: Das Laden von HTTP-Ressourcen auf einer HTTPS-Seite bricht die Sicherheit. Verwenden Sie relative URLs oder stellen Sie sicher, dass alle Ressourcen HTTPS sind.
• Schwache Cipher Suites: Deaktivieren Sie veraltete Protokolle (TLS 1.0, 1.1) und schwache Cipher (RC4, 3DES). Aktivieren Sie TLS 1.3.
• Fehlendes HSTS: Fügen Sie den Header Strict-Transport-Security hinzu, um HTTPS für zukünftige Besuche zu erzwingen.
• Unvollständige Zertifikatsketten: Einige Server vergessen, Zwischenzertifikate einzubinden, was bei manchen Clients zu Fehlern führt. Testen Sie mit SSL Labs.

TLS-Performance optimieren

TLS verursacht Latenz durch den Handshake. So minimieren Sie sie:

• Aktivieren Sie TLS 1.3, das einen schnelleren Handshake hat.
• Verwenden Sie Session Resumption (Session Tickets oder Pre-Shared Keys), um vollständige Handshakes für wiederkehrende Besucher zu vermeiden.
• Aktivieren Sie OCSP-Stapling, um die Latenz bei der Zertifikatsvalidierung zu reduzieren.
• Verwenden Sie ein CDN mit TLS-Terminierung am Edge, um Round-Trip-Zeiten zu reduzieren.
• Halten Sie Zertifikate klein (verwenden Sie ECDSA statt RSA, wo möglich).

FAQ

Was ist der Unterschied zwischen HTTPS und TLS?

HTTPS ist die sichere Version von HTTP, und TLS ist das kryptographische Protokoll, das die Sicherheit bietet. HTTPS verwendet TLS, um die Verbindung zu verschlüsseln und zu authentifizieren.

Wie bietet TLS Forward Secrecy?

Forward Secrecy stellt sicher, dass selbst wenn der private Schlüssel des Servers kompromittiert wird, vergangene Sitzungsschlüssel nicht abgeleitet werden können. Dies wird durch die Verwendung von ephemerem Diffie-Hellman-Schlüsselaustausch (ECDHE) in TLS 1.3 und modernen TLS 1.2-Konfigurationen erreicht.

Warum sehe ich Zertifikatsfehler auf einigen Websites?

Zertifikatsfehler bedeuten normalerweise, dass das Zertifikat abgelaufen, selbstsigniert, für eine andere Domain ausgestellt ist oder die Zertifikatskette unvollständig ist. Browser lehnen solche Zertifikate ab, um Sie vor Man-in-the-Middle-Angriffen zu schützen.

Wenn Sie TLS-Verbindungen inspizieren oder debuggen müssen, können Tools wie der Timestamp Converter Ihnen helfen, Gültigkeitszeiträume von Zertifikaten zu entschlüsseln und zeitbezogene Probleme zu debuggen.