Wie HTTPS und TLS wirklich funktionieren: Unter der Haube

Security2026-11-08TryQuickToolBox

Sie geben eine URL ein, drücken die Eingabetaste und sehen das Schloss. Aber was passiert tatsächlich zwischen Ihrem Browser und dem Server, um diese Verbindung sicher zu machen? Viele Entwickler betrachten HTTPS als Blackbox – bis etwas schiefgeht, wie ein Zertifikatsfehler oder ein Leistungsproblem. Dieser Artikel lüftet den Vorhang über HTTPS und TLS und erklärt den Handshake, die Verschlüsselung und die Zertifikatsvalidierung in praktischen Begriffen.

Was HTTPS wirklich ist

HTTPS ist einfach 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 echten Server, nicht mit einem Betrüger.

TLS entwickelte sich aus SSL (Secure Sockets Layer). Moderne Versionen (TLS 1.2 und 1.3) sollten Sie verwenden; SSL ist veraltet.

Der TLS-Handshake: Schritt für Schritt

Bevor HTTP-Daten fließen, führen Client und Server einen Handshake durch, um sich auf Verschlüsselungsschlüssel zu einigen. Hier ist, was in einem typischen TLS 1.3-Handshake (vereinfacht) passiert:

Client Hello: Der Browser sendet eine Liste unterstützter Cipher Suites, einen Zufallswert und seinen Schlüsselanteil für den Schlüsselaustausch.
Server Hello: Der Server wählt eine Cipher Suite, sendet seinen eigenen Zufallswert und Schlüsselanteil und präsentiert sein Zertifikat.
Schlüsselableitung: Beide Seiten berechnen dasselbe gemeinsame Geheimnis mithilfe des Diffie-Hellman-Schlüsselaustauschs. Daraus leiten sie Sitzungsschlüssel für die symmetrische Verschlüsselung ab.
Finished: Beide Parteien senden einen MAC (Message Authentication Code), um die Integrität des Handshakes zu überprüfen. Verschlüsselte Anwendungsdaten können nun fließen.

TLS 1.3 reduzierte den Handshake auf einen Roundtrip (1-RTT) und unterstützt sogar 0-RTT für fortgesetzte Sitzungen, was die Latenz verbessert.

Schlüsselaustausch: Diffie-Hellman

Das Magische an modernem TLS ist, dass Client und Server sich auf ein gemeinsames Geheimnis einigen können, ohne es jemals zu übertragen. Diffie-Hellman (genauer ECDHE für elliptische Kurven) ermöglicht dies. Selbst wenn ein Angreifer den gesamten Handshake aufzeichnet, kann er den Sitzungsschlüssel nicht ableiten – diese Eigenschaft nennt man Forward Secrecy.

Symmetrische Verschlüsselung: AES oder ChaCha20

Sobald das gemeinsame Geheimnis etabliert ist, wechselt TLS zur symmetrischen Verschlüsselung (wie AES-GCM oder ChaCha20-Poly1305), weil diese viel schneller als asymmetrische Kryptographie ist. Die Sitzungsschlüssel werden verwendet, um alle Anwendungsdaten zu verschlüsseln.

Zertifikatsvalidierung: Vertrauen, aber prüfen

Das Zertifikat des Servers ist zentral für die Authentifizierung. Es enthält den öffentlichen Schlüssel des Servers und ist von einer Zertifizierungsstelle (CA) signiert. So validiert der Browser es:

Vertrauenskette: Das Zertifikat muss zu einer vertrauenswürdigen Root-CA führen, die im Browser oder Betriebssystem vorinstalliert ist.
Hostname-Übereinstimmung: Das Zertifikat muss für die Domain gültig sein, die Sie besuchen (über Subject Alternative Names).
Gültigkeitszeitraum: Das Zertifikat darf nicht abgelaufen oder noch nicht gültig sein.
Sperrung: Der Browser kann OCSP oder CRL prüfen, um sicherzustellen, dass das Zertifikat nicht widerrufen wurde.

Wenn eine Prüfung fehlschlägt, erhalten Sie eine Warnung – wie „Ihre Verbindung ist nicht privat“.

Häufige TLS-Fehlkonfigurationen

Selbst mit aktiviertem HTTPS können Fehler die Sicherheit schwächen:

Veraltete Protokolle: Die Unterstützung von TLS 1.0/1.1 oder SSLv3 setzt Sie bekannten Angriffen aus.
Schwache Cipher Suites: Die Zulassung von RC4- oder CBC-Modus-Cipher ohne Gegenmaßnahmen.
Fehlendes HSTS: Ohne HTTP Strict Transport Security können Benutzer auf HTTP herabgestuft werden.
Zertifikatsfehlmanagement: Abgelaufene Zertifikate oder unsachgemäße Kettenkonfiguration.

Verwenden Sie Tools wie den SSL Labs SSL Test, um Ihre Konfiguration zu überprüfen.

Praktisches Beispiel: HTTPS mit Nginx aktivieren

Hier ist eine minimale Nginx-Konfiguration für einen sicheren HTTPS-Server:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    add_header Strict-Transport-Security "max-age=63072000" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Diese Konfiguration verwendet Let's Encrypt-Zertifikate, aktiviert nur TLS 1.2 und 1.3 und setzt HSTS.

FAQ

Was ist der Unterschied zwischen TLS und SSL?

TLS ist der Nachfolger von SSL. SSL-Versionen (2.0, 3.0) sind aufgrund von Sicherheitslücken veraltet. Wenn Leute „SSL-Zertifikat“ sagen, meinen sie normalerweise ein TLS-Zertifikat.

Macht HTTPS meine Website langsam?

Modernes TLS (1.3) fügt minimale Latenz hinzu – oft nur wenige Millisekunden. Mit Session Resumption und HTTP/2 kann HTTPS genauso schnell oder schneller als HTTP sein.

Wie bekomme ich ein kostenloses TLS-Zertifikat?

Let's Encrypt bietet kostenlose, automatisierte Zertifikate. Tools wie Certbot können sie für Sie beantragen und erneuern.

Fazit

HTTPS und TLS sind keine Magie – sie sind gut konzipierte Protokolle, die Public-Key-Kryptographie zur Authentifizierung mit symmetrischer Verschlüsselung für Geschwindigkeit kombinieren. Das Verständnis des Handshakes und der Zertifikatsvalidierung hilft Ihnen, Probleme zu beheben und Ihre Server sicher zu konfigurieren. Verwenden Sie immer TLS 1.2 oder 1.3, halten Sie Zertifikate aktuell und aktivieren Sie HSTS.

Für die Analyse von Server-Logs zur Erkennung von TLS-Fehlern oder Leistungsproblemen probieren Sie unseren Nginx Log Analyzer.