Wie HTTPS und TLS wirklich funktionieren: Ein praktischer Leitfaden

Security2026-11-10TryQuickToolBox

Sie haben wahrscheinlich schon das Schloss-Symbol in Ihrem Browser gesehen und wissen, dass es "sicher" bedeutet. 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 die Dinge? Dieser Leitfaden erklärt HTTPS und TLS in praktischen Begriffen, damit Sie Ihre Webanwendungen sicher konfigurieren, debuggen und absichern können.

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: Der Server beweist seine Identität mithilfe eines Zertifikats.

Ohne TLS sendet HTTP alles im Klartext: Passwörter, Cookies und persönliche Daten sind für jeden auf dem Netzwerkpfad sichtbar. HTTPS behebt das.

Der TLS-Handshake auf Deutsch

Bevor verschlüsselte Daten fließen, führen Client und Server einen Handshake durch, um sich auf Verschlüsselungsschlüssel zu einigen und die Identität zu überprüfen. So läuft ein typischer TLS-1.3-Handshake (der moderne Standard) ab:

Client Hello: Der Browser sendet eine Liste unterstützter Cipher Suites, TLS-Versionen und einen Zufallswert.
Server Hello: Der Server wählt eine Cipher Suite, sendet seinen eigenen Zufallswert und stellt seine Zertifikatskette bereit.
Schlüsselaustausch: Beide Seiten verwenden einen Schlüsselaustauschalgorithmus (wie ECDHE), um ein gemeinsames Geheimnis abzuleiten, ohne es jemals direkt zu übertragen.
Zertifikatsprüfung: Der Client prüft das Serverzertifikat gegen vertrauenswürdige Root-CAs, validiert den Domainnamen und prüft das Ablaufdatum.
Finished: Beide Seiten senden einen MAC, um die Integrität des Handshakes zu bestätigen, und verschlüsselte Anwendungsdaten beginnen.

TLS 1.3 reduziert dies auf einen einzigen Roundtrip (1-RTT) und unterstützt sogar 0-RTT-Wiederaufnahme für wiederkehrende Besucher, was die Latenz im Vergleich zu TLS 1.2 erheblich senkt.

Zertifikate: Der Vertrauensanker

Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Domainnamen und wird von einer Zertifizierungsstelle (CA) signiert. Browser und Betriebssysteme werden mit einem Speicher vertrauenswürdiger Root-CAs ausgeliefert. Wenn ein Server sein Zertifikat präsentiert, überprüft der Client die Kette bis zu einer vertrauenswürdigen Root.

Gängige Zertifikatstypen:

DV (Domain Validated): Bestätigt die Kontrolle über die Domain; wird schnell und oft kostenlos ausgestellt (z. B. Let's Encrypt).
OV (Organization Validated): Enthält verifizierte Organisationsdetails; die Ausstellung dauert länger.
EV (Extended Validation): Höchste Validierungsstufe; zeigte historisch eine grüne Adressleiste, aber moderne Browser betonen dies nicht mehr.

Zertifikate laufen ab, daher ist Automatisierung unerlässlich. Tools wie Certbot oder ACME-Clients, die in Ihren Reverse-Proxy integriert sind, übernehmen die Erneuerung automatisch.

HTTPS auf Ihrem Server konfigurieren

Hier ist eine minimale Nginx-Konfiguration, die HTTPS mit modernen TLS-Einstellungen aktiviert:

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;

    # HSTS (nach dem Testen aktivieren)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

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

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

Wichtige Punkte: Verwenden Sie nur TLS 1.2 und 1.3, bevorzugen Sie ECDHE-Cipher-Suites für Forward Secrecy und leiten Sie HTTP auf HTTPS um. HSTS weist Browser an, für Ihre Domain immer HTTPS zu verwenden, aber testen Sie sorgfältig, bevor Sie es mit einer langen max-age aktivieren.

Häufige Fallstricke und wie man sie vermeidet

Gemischte Inhalte: Das Laden von HTTP-Ressourcen auf einer HTTPS-Seite bricht das Schloss-Symbol. Verwenden Sie relative URLs oder stellen Sie sicher, dass alle Assets über HTTPS geladen werden.
Abgelaufene Zertifikate: Automatisieren Sie die Erneuerung und überwachen Sie den Ablauf. Ein abgelaufenes Zertifikat führt zu sofortigen Browserwarnungen.
Schwache Protokolle: Deaktivieren Sie TLS 1.0 und 1.1; sie sind veraltet und anfällig.
Unvollständige Zertifikatsketten: Server müssen Zwischenzertifikate senden; andernfalls schlagen einige Clients fehl. Testen Sie mit Tools wie SSL Labs.
Kein HSTS-Preload: Für maximalen Schutz reichen Sie Ihre Domain nach Sicherstellung, dass alle Subdomains HTTPS unterstützen, in die HSTS-Preload-Liste ein.

TLS 1.2 vs. TLS 1.3: Was hat sich geändert

Funktion	TLS 1.2	TLS 1.3
Handshake-Roundtrips	2-RTT	1-RTT (0-RTT mit Wiederaufnahme)
Schlüsselaustausch	RSA oder ECDHE	Nur ECDHE (Forward Secrecy obligatorisch)
Cipher Suites	Viele, auch schwache	Reduzierte Menge, alle AEAD
0-RTT-Daten	Nicht unterstützt	Unterstützt (mit Replay-Risiko)

TLS 1.3 ist schneller und einfacher und entfernt Legacy-Algorithmen. Die meisten modernen Clients unterstützen es, aber behalten Sie TLS 1.2 für ältere Geräte bei.

TLS-Probleme debuggen

Wenn HTTPS fehlschlägt, prüfen Sie Folgendes:

Verwenden Sie openssl s_client -connect example.com:443 -servername example.com, um die Zertifikatskette und den Handshake zu inspizieren.
Führen Sie curl -vI https://example.com aus, um die ausgehandelte TLS-Version und Cipher Suite zu sehen.
Prüfen Sie Server-Logs auf Handshake-Fehler; Nginx protokolliert SSL-Fehler im Error-Log.
Verwenden Sie Online-SSL-Tester, um eine umfassende Bewertung und Empfehlungen zu erhalten.

Wenn Sie regelmäßig mit Nginx-Logs arbeiten, kann Ihnen der Nginx Log Analyzer helfen, TLS-Handshake-Fehler und andere Probleme schnell zu erkennen.

FAQ

Was ist der Unterschied zwischen HTTPS und TLS?

HTTPS ist HTTP über TLS. TLS ist das kryptografische Protokoll, das Verschlüsselung, Integrität und Authentifizierung bietet. HTTPS ist die sichere Version von HTTP, die TLS verwendet.

Brauche ich ein Zertifikat für interne Dienste?

Ja, für interne Produktionsdienste verwenden Sie Zertifikate von Ihrer eigenen CA oder einer öffentlichen CA. Selbstsignierte Zertifikate verursachen Vertrauensprobleme; ziehen Sie eine private PKI oder Tools wie mkcert für die Entwicklung in Betracht.

Wie oft sollten Zertifikate erneuert werden?

Die moderne Best Practice sind 90-Tage-Zertifikate mit automatischer Erneuerung, wie sie von Let's Encrypt angeboten werden. Kürzere Laufzeiten reduzieren das Risiko, wenn ein Schlüssel kompromittiert wird.

Bereit, Ihre Website abzusichern? Beginnen Sie damit, Ihre aktuelle TLS-Konfiguration mit einem SSL-Checker zu testen, und wenden Sie dann die oben genannten Nginx-Einstellungen an. Für einen tieferen Einblick in die Web-Sicherheit erkunden Sie unsere anderen Leitfäden zu OWASP Top 10 und XSS-Prävention.