Begriff
mTLS (Mutual TLS)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Bei normalem HTTPS (z. B. Amazon.com) zeigt der Server seinen Ausweis (Zertifikat). "Ich bin Amazon". Der Browser prüft das. Aber Amazon weiß nicht, wer du bist (Authentifizierung erfolgt erst später per Passwort). Bei mTLS zeigen beide ihren Ausweis. Der Server zeigt sein Zertifikat. Und der Client (Browser oder anderer Server) zeigt auch ein Zertifikat. Wenn der Client kein gültiges Zertifikat hat, wird die Verbindung sofort auf Netzwerk-Ebene getrennt. Es ist extrem sicher, weil keine Passwörter übertragen werden. Es wird oft zwischen Servern (Microservices) eingesetzt ("Zero Trust").
Merksatz: Eine Erweiterung von TLS, bei der sich sowohl der Server als auch der Client gegenseitig mittels digitaler Zertifikate authentifizieren, bevor eine verschlüsselte Verbindung aufgebaut wird.
Ohne mTLS:
Server A -> curl https://server-b (Server B vertraut jedem).
Mit mTLS:
Server A braucht:
client.crt(Öffentlich).client.key(Geheim!).ca.crt(Zum Prüfen von Server B). Server B braucht:server.crt.server.key.ca.crt(Zum Prüfen von Server A). Konfiguration in Nginx:
ssl_client_certificate /etc/nginx/ca.crt;
ssl_verify_client on;
Wenn du jetzt ohne Zertifikat kommst: 400 Bad Request - No required SSL certificate was sent.
1. Service Mesh (Istio / Linkerd)
Hunderte Zertifikate manuell zu verteilen und zu rotieren (alle 90 Tage) ist die Hölle. Ein Service Mesh automatisiert das. Jeder Pod bekommt einen Sidecar-Proxy. Der Proxy holt sich beim Start automatisch ein Zertifikat von der internen CA. Er rotiert es alle 60 Minuten (!). Er tunnelt allen Traffic zu anderen Pods per mTLS. Die App selbst (Code) merkt davon nichts ("Transparent mTLS"). Das ist der Standard für Zero Trust in Kubernetes.
2. SPIFFE / SPIRE
Wie identifiziert man Workloads? IP-Adressen ändern sich. SPIFFE ist ein Standard für Identität ("spiffe://my-cluster/ns/default/sa/frontend"). SPIRE ist die Software, die Zertifikate mit dieser ID ausstellt (basierend auf Attestation: "Bist du wirklich der Prozess auf Node X?"). Das entkoppelt Identität vom Netzwerk.
3. Revocation (CRL / OCSP)
Was, wenn ein Client-Key (Laptop) geklaut wird? Du musst das Zertifikat sperren. Das ist bei mTLS schwer. Der Server muss eine CRL (Sperrliste) prüfen oder OCSP nutzen. Bei kurzlebigen Zertifikaten (60 min) im Service Mesh ignoriert man das oft ("Warte einfach eine Stunde, dann ist es eh ungültig").
1. TLS Handshake & RSA Signature Cost
Im Standard-TLS sendet der Client ein ClientHello, der Server antwortet mit ServerHello und seinem Zertifikat. Bei mTLS fordert der Server im ServerHello-Prozess explizit ein CertificateRequest vom Client.
Das Problem: Der mTLS Handshake verschlingt auf beiden Seiten brutale asymmetrische Krypto-Zyklen (z. B. RSA-2048 oder ECDSA). Der Client muss sein Secret beweisen, indem er den gesamten Handshake-Verlauf (CertificateVerify Message) mit seinem Private Key durch-signiert. In einer Microservice-Mesh Architektur, bei der 500 Container pro Sekunde tausende kurzlebiger TCP-Connections aufreißen, explodiert die L1-CPU-Cache Last an elliptischen Kurvenberechnungen (TLS-Terminierungs-Bottleneck). Moderne Meshes parieren dies durch starkes "Connection Pooling" (L4 Proxying via Envoy), so dass der aufwendige mTLS Handshake nur 1x pro Stunde zwischen den Nodes gemacht wird, während die HTTP/2 Streams asynchron über einen langlebigen Tunnel multiplexen.
2. TLS Bumping & Forward Secrecy Anomalien
Eine fatale Folge von mTLS in Enterprise Firmen-Netzwerken betrifft Corporate Firewalls (Deep Packet Inspection – DPI).
Viele IT-Abteilungen machen TLS Bumping (Man-in-the-Middle Inspection) per Proxy-CA-Einschleusung auf Firmen-Laptops, um Traffic auf Viren zu scannen.
Bei mTLS kollabiert dieses System unweigerlich. Die Security-Appliance in der Mitte kann zwar das Server-Zertifikat fälschen, aber sie kann unmöglich das Client-Zertifikat fälschen, da der Private Key hardwaregeschützt auf dem Smartcard/TPM des Users liegt! Die Middlebox scheitert am CertificateVerify. Man muss also Whitelist-Bypasses einpflegen. Das erzwingt zudem, dass extrem sensible APIs absolut unangreifbar für interne Netzwerk-Schnüffler (Zero-Trust am Layer 4) werden, sofern "Perfect Forward Secrecy" Ciphers (z. B. ECDHE) erzwungen sind.
3. SPIFFE X.509 SVID (Short-Lived Certificates)
Das Verwalten von Schlüsseln war einst die Hölle (Revocation Lists - CRLs, die nie updaten). Das SPIFFE/SPIRE Protokoll revolutionierte Kubernetes durch Zero-Touch Identity. Ein Container bootet und spricht mit dem Node-Agent (SPIRE Agent) über einen Unix Domain Socket. Der Agent beweist dem SPIRE Server über Kernel-Cgroups ("PID 541 gehört zu Pod A"), wer da fragt. SPIRE generiert blind ein X.509 SVID (das mTLS Zertifikat). Der massive Produktions-Trick: Diese SVIDs sind extrem kurzliebig (oft nur TTL = 1 Stunde). Dadurch entfällt das gesamte fehleranfällige OCSP/CRL Checking System. Sollte ein Hacker den RAM eines Pods auslesen, ist sein erbeuteter Key in maximal 59 Minuten für immer wertloser Kryptomüll im gesamten Datacenter.
Quick-Check
Ersetzt mTLS OAuth/JWT?
Nein. mTLS authentifiziert die Maschine (Service A). JWT authentifiziert den User (Max Mustermann), der die Anfrage ausgelöst hat. Man nutzt beides: mTLS für den Tunnel, JWT im Header für den User-Context.Performance-Kosten?
Der Handshake dauert etwas länger (Client muss Signieren & Senden). Aber die Verschlüsselung (Symmetrisch AES) ist danach genauso schnell wie normales HTTPS. CPU-Overhead ist heute vernachlässigbar.Debugging?
Schmerzhaft. Du kannst mit Wireshark nicht mehr reinschauen.curlgeht nicht mehr einfach so. Du brauchst spezielle Debug-Pods mit den richtigen Zertifikaten ("Netshoot").