TLS (Transport Layer Security) - Definition & Erklärung

TLS (Transport Layer Security) ist das meistgenutzte kryptographische Protokoll der Welt. Jede HTTPS-Verbindung, jede E-Mail-Übertragung (STARTTLS), jede VPN-Verbindung (OpenVPN, SSL-VPN) und viele weitere Protokolle nutzen TLS als Sicherheitsschicht.

TLS vs. SSL: Die Unterschiede

SSL (Secure Sockets Layer) war der Vorläufer von TLS, entwickelt von Netscape in den 1990ern. Alle SSL-Versionen (1.0, 2.0, 3.0) und TLS 1.0 und 1.1 sind heute als unsicher eingestuft und deaktiviert.

SSL 2.0 (1995) → unsicher, veraltet
SSL 3.0 (1996) → POODLE-Angriff, veraltet
TLS 1.0 (1999) → BEAST/POODLE, RFC 8996 deprecated
TLS 1.1 (2006) → RFC 8996 deprecated
TLS 1.2 (2008) → aktuell, weit verbreitet
TLS 1.3 (2018) → empfohlen, schneller und sicherer

Im Volksmund sagt man oft noch “SSL” - gemeint ist fast immer TLS.

Der TLS-Handshake (vereinfacht)

TLS 1.2 (vereinfacht):

Client                          Server
  |                               |
  |── ClientHello ──────────────→ |  (TLS-Version, Cipher Suites, Random)
  |← ServerHello ────────────────|  (gewählte Cipher Suite, Random)
  |← Certificate ────────────────|  (Zertifikat des Servers)
  |← ServerHelloDone ────────────|
  |── ClientKeyExchange ────────→ |  (Pre-Master Secret, verschlüsselt)
  |── ChangeCipherSpec ─────────→ |
  |── Finished ──────────────── → |  (MAC über gesamten Handshake)
  |← ChangeCipherSpec ───────────|
  |← Finished ───────────────────|
  |                               |
  |═══ Verschlüsselte App-Daten ══|

TLS 1.3 (verbessert):

1-RTT Handshake (statt 2-RTT bei TLS 1.2) → schnellere Verbindungen
0-RTT für Verbindungswiederherstellung (mit Sicherheits-Trade-offs)
Kein RSA-Schlüsselaustausch mehr - nur (EC)DHE für Forward Secrecy
Alle schwachen Cipher Suites entfernt
Vereinfachtes Protokoll (weniger Angriffsfläche)

TLS-Sicherheitsmerkmale

Verschlüsselung: Alle übertragenen Daten sind verschlüsselt - kein Abhören (auch nicht durch ISP oder Netzwerkbetreiber).

Server-Authentifizierung: Das Server-Zertifikat beweist die Identität (durch PKI-Kette zu einer vertrauenswürdigen CA). Schützt vor Man-in-the-Middle-Angriffen wenn korrekt validiert.

Forward Secrecy (PFS): Ephemere Diffie-Hellman-Schlüssel (DHE/ECDHE) stellen sicher: Selbst wenn der langfristige Server-Private-Key kompromittiert wird, können vergangene Sitzungen nicht nachträglich entschlüsselt werden. Bei TLS 1.3 obligatorisch.

Integrity: HMAC (oder AEAD-Algorithmen) stellen sicher, dass Daten nicht unbemerkt manipuliert werden können.

Cipher Suites

Eine Cipher Suite beschreibt die verwendeten Algorithmen. Beispiel:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_         → Protokoll
ECDHE_       → Schlüsselaustausch (Elliptic Curve DHE → Forward Secrecy)
RSA_         → Authentifizierung (Server-Zertifikat Typ)
WITH_        → Trenner
AES_256_GCM_ → Verschlüsselung + Modus
SHA384       → Hashing für HMAC

Empfohlene Cipher Suites (BSI TR-02102-2):

TLS 1.3:
  TLS_AES_256_GCM_SHA384
  TLS_CHACHA20_POLY1305_SHA256
  TLS_AES_128_GCM_SHA256

TLS 1.2 (Rückwärtskompatibilität):
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Unsichere Cipher Suites (sofort deaktivieren):

NULL-Cipher (keine Verschlüsselung)
RC4 (BEAST-Angriff)
3DES (SWEET32-Angriff)
DES, Export-Cipher (40-Bit-Schlüssel)
MD5 als Hash-Algorithmus

Häufige TLS-Schwachstellen

Veraltete Protokollversionen: Server die noch TLS 1.0 oder SSL 3.0 unterstützen sind angreifbar (BEAST, POODLE).

Schwache Cipher Suites: Konfigurationsfehler erlauben Downgrade auf schwache Algorithmen (FREAK, LOGJAM).

Zertifikats-Validierungsfehler:

Abgelaufene Zertifikate → Browser-Warnung, Nutzer klicken durch (“Click-Through”)
Self-Signed-Zertifikate → keine CA-Verifikation
Fehlende Hostname-Validierung in Apps → MITM möglich

HSTS nicht gesetzt: Ohne HTTP Strict Transport Security (HSTS) kann ein Angreifer SSL-Stripping durchführen (Downgrade auf HTTP).

Certificate Pinning fehlt (mobile Apps): Ohne Pinning kann ein Angreifer mit einem eigenen CA-Zertifikat MITM durchführen.

TLS in der Praxis testen

# TLS-Konfiguration testen (nmap)
nmap --script ssl-enum-ciphers -p 443 example.com

# SSL Labs API (A+ bis F Rating)
# Aufruf über Browser: ssllabs.com/ssltest/

# testssl.sh - lokaler Test
./testssl.sh --severity HIGH example.com

# OpenSSL - Version und Zertifikat prüfen
openssl s_client -connect example.com:443 -tls1_3
openssl s_client -connect example.com:443 | openssl x509 -noout -dates

TLS-Konfigurationsempfehlung

# nginx - Empfehlung BSI TR-02102-2
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

# HSTS (mind. 1 Jahr, includeSubDomains)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;

Mutual TLS (mTLS)

Bei Standard-TLS authentifiziert sich nur der Server per Zertifikat. Bei mTLS authentifizieren sich beide Seiten:

Client → präsentiert Client-Zertifikat → Server
Server → präsentiert Server-Zertifikat → Client

Anwendungsfälle:

Microservices-Kommunikation (Zero-Trust-Prinzip: kein implizites Netzvertrauen)
API-Authentifizierung (statt API-Keys)
VPN-Client-Authentifizierung
Zero-Trust-Netzwerke

mTLS ist die technische Grundlage vieler Zero-Trust-Architekturen (SPIFFE/SPIRE, Istio Service Mesh).