HTTPS und TLS verstehen: Ein praktischer Leitfaden

Sie haben das Schloss-Symbol in Ihrem Browser gesehen und wissen, dass HTTPS wichtig ist. Aber verstehen Sie wirklich, was passiert, wenn ein Browser eine Verbindung zu einer HTTPS-Website herstellt? Viele Entwickler behandeln TLS als Blackbox – einmal konfiguriert und vergessen. Das funktioniert so lange, bis etwas kaputtgeht, die Leistung leidet oder ein Sicherheitsaudit Fehlkonfigurationen aufdeckt.

Dieser Leitfaden erklärt HTTPS und TLS in praktischen Begriffen. Sie lernen den Handshake-Prozess kennen, wie Zertifikate Vertrauen aufbauen und welche Schritte zur korrekten Implementierung von TLS auf Ihren Servern erforderlich sind. Kein Fachjargon-Overload – nur die Konzepte, die Sie benötigen, um Probleme zu beheben und fundierte Entscheidungen zu treffen.

Was HTTPS tatsächlich ist

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

• Verschlüsselung: Die zwischen Client und Server ausgetauschten Daten sind für Lauscher unlesbar.
• Authentifizierung: Der Client überprüft, ob er mit dem legitimen Server und nicht mit einem Betrüger spricht.
• Integrität: Daten können während der Übertragung nicht unbemerkt verändert werden.

TLS ist das Protokoll, das dies ermöglicht. SSL ist sein Vorgänger – in der Werbung werden Sie noch „SSL-Zertifikate“ sehen, aber moderne Systeme verwenden TLS (derzeit ist TLS 1.3 der neueste Standard).

Der TLS-Handshake: Schritt für Schritt

Bevor HTTP-Daten fließen, führen Client und Server einen Handshake durch, um sich auf Verschlüsselungsparameter zu einigen und Identitäten zu überprüfen. Hier ist der vereinfachte Ablauf für TLS 1.3, den modernen Standard:

1. Client Hello: Der Browser sendet eine Liste unterstützter Cipher Suites, TLS-Versionen und einen Zufallswert (Client Random).
2. Server Hello: Der Server wählt eine Cipher Suite, sendet seinen eigenen Zufallswert (Server Random) und stellt seine Zertifikatskette bereit.
3. Schlüsselaustausch: Mittels ephemerem Diffie-Hellman (oder ähnlich) leiten beide Parteien ein gemeinsames Geheimnis ab, ohne es direkt zu übertragen. Dies bietet Forward Secrecy – die spätere Kompromittierung des privaten Serverschlüssels entschlüsselt vergangene Sitzungen nicht.
4. Zertifikatsüberprüfung: Der Client prüft das Zertifikat gegen vertrauenswürdige Root-CAs, validiert den Domainnamen und prüft Ablauf- und Sperrstatus.
5. Finished: Beide Seiten senden einen MAC (Message Authentication Code), um zu bestätigen, dass der Handshake nicht manipuliert wurde. Verschlüsselter HTTP-Datenverkehr beginnt.

TLS 1.3 reduzierte den Handshake auf einen Roundtrip (1-RTT) und unterstützt 0-RTT-Wiederaufnahme für wiederkehrende Besucher, was die Latenz verbessert. TLS 1.2 erforderte zwei Roundtrips.

Zertifikate: Der Vertrauensanker

Ein TLS-Zertifikat bindet einen öffentlichen Schlüssel an einen Domainnamen und wird von einer Zertifizierungsstelle (CA) signiert. Wenn Ihr Browser eine Verbindung zu example.com herstellt, prüft er, ob das Zertifikat:

• Von einer CA in seinem Trust Store signiert ist (oder zu einer solchen verkettet).
• Mit dem Domainnamen übereinstimmt (über Subject Alternative Names).
• Innerhalb seines Gültigkeitszeitraums liegt.
• Nicht gesperrt wurde (über OCSP oder CRL, wobei die Durchsetzung variiert).

Sie können Zertifikate kostenlos von Let's Encrypt erhalten, das 90-Tage-Zertifikate über das ACME-Protokoll ausstellt. Automatisierungstools wie Certbot übernehmen die Erneuerung. Für interne Dienste können Sie Ihre eigene CA betreiben, aber Clients müssen dieser explizit vertrauen.

TLS auf Ihrem Server konfigurieren

Eine ordnungsgemäße Konfiguration balanciert Sicherheit, Kompatibilität und Leistung aus. Hier ist eine Checkliste:

• Nur TLS 1.2 und 1.3 verwenden. Deaktivieren Sie TLS 1.0 und 1.1 – sie sind veraltet und anfällig.
• Starke Cipher Suites wählen. Bevorzugen Sie AEAD-Cipher wie AES-GCM oder ChaCha20-Poly1305. Vermeiden Sie CBC-Modus und RC4.
• Forward Secrecy aktivieren. Verwenden Sie ECDHE-Schlüsselaustausch.
• OCSP-Stapling aktivieren. Der Server fügt eine zwischengespeicherte OCSP-Antwort bei, was clientseitige Latenz und Datenschutzlecks reduziert.
• HSTS-Header setzen. Zwingen Sie Browser, HTTPS für zukünftige Besuche zu verwenden.
• HTTP auf HTTPS umleiten. Stellen Sie sicher, dass kein Klartextverkehr ausgeliefert wird.

Für Nginx sieht eine minimale sichere Konfiguration so aus:

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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8;

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

    location / {
        proxy_pass http://localhost:3000;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Testen Sie Ihre Konfiguration mit Tools wie dem SSL Test von SSL Labs oder testssl.sh. Streben Sie eine A-Bewertung an, aber jagen Sie nicht perfekten Ergebnissen hinterher, wenn Sie dadurch ältere Clients brechen, die Sie unterstützen müssen.

Häufige Fallstricke und wie man sie vermeidet

• Abgelaufene Zertifikate: Automatisieren Sie die Erneuerung und überwachen Sie den Ablauf. Ein einziges abgelaufenes Zertifikat kann Ihre Website lahmlegen.
• Gemischte Inhalte: Das Laden von HTTP-Ressourcen auf einer HTTPS-Seite löst Warnungen aus und beeinträchtigt die Funktionalität. Verwenden Sie relative URLs oder durchgängig HTTPS.
• Schwache Protokolle: TLS 1.0/1.1 sind veraltet. Aktualisieren Sie Ihre Konfiguration.
• Fehlende Zwischenzertifikate: Der Server muss die vollständige Kette senden (außer dem Root). Fehlende Zwischenzertifikate verursachen Vertrauensfehler bei einigen Clients.
• Unsachgemäße Weiterleitungen: Leiten Sie HTTP vor dem Ausliefern von Inhalten auf HTTPS um und verwenden Sie 301 für permanente Weiterleitungen.

FAQ

Was ist der Unterschied zwischen HTTPS und TLS?

HTTPS ist HTTP über TLS. TLS ist das kryptografische Protokoll, das Verschlüsselung, Authentifizierung und Integrität bietet. Ohne TLS gibt es kein HTTPS.

Brauche ich ein separates Zertifikat für www und non-www?

Sie können beide im Feld Subject Alternative Names (SAN) eines einzigen Zertifikats einschließen. Die meisten CAs stellen standardmäßig oder mit einer einfachen Konfiguration Zertifikate aus, die beide abdecken.

Wie oft sollte ich meine TLS-Zertifikate rotieren?

Folgen Sie der Gültigkeitsdauer der CA – 90 Tage bei Let's Encrypt. Automatisieren Sie die Erneuerung mit einem Cron-Job oder systemd-Timer. Rotieren Sie sofort, wenn ein privater Schlüssel kompromittiert wurde.

Bereit, Ihren Web-Traffic zu inspizieren? Verwenden Sie den Nginx Log Analyzer, um Zugriffsprotokolle zu analysieren und HTTPS-Anfragen, Statuscodes und potenzielle Probleme zu überprüfen.