Was TLS leistet und was nicht

Transport Layer Security (TLS) ist das Protokoll, das den Datenverkehr zwischen Client und Server verschlüsselt. Im Web ist es die S in HTTPS. TLS löst drei Aufgaben auf der Transportschicht: Vertraulichkeit (der Verkehr ist verschlüsselt), Integrität (Manipulation am Datenstrom wird erkannt) und Server-Authentifizierung (der Client prüft per Zertifikat, dass er wirklich mit dem erwarteten Server spricht). Damit schützt TLS vor Abhören und Man-in-the-Middle-Angriffen auf dem Netzwerkpfad.

Entscheidend für API-Security ist die Grenze: TLS sagt nichts darüber aus, was ein authentifizierter Aufrufer tun darf. Es ist eine reine Transportabsicherung, keine Anwendungs-Autorisierung. Ein vollständig per TLS gesicherter Aufruf kann trotzdem ein fremdes Objekt lesen (BOLA), eine privilegierte Funktion auslösen (BFLA) oder geleakte Felder zurückbekommen (BOPLA). Wer du bist und was diese Anfrage darf, klärt erst die Authentifizierung und Autorisierung in der Anwendung. TLS verschlüsselt also den Tunnel, aber es bewacht nicht die Tür dahinter.

AspektTLS (Server-Auth)mTLS (beidseitig)
Wer weist sich ausnur der Server gegenüber dem ClientServer und Client gegenseitig
Typischer EinsatzBrowser zu Web/API, öffentliche EndpunkteService-zu-Service, M2M-APIs, Zero-Trust-Netze
ZertifikateServer-Zertifikat von öffentlicher CAzusätzlich Client-Zertifikate, oft eigene interne CA
Schützt vorAbhören, Manipulation, Server-Spoofingzusätzlich: unbekannte/unautorisierte Aufrufer
Betriebsaufwandmoderat, etablierte CA-Prozessehoch: Verteilung und Rotation vieler Client-Zertifikate (z. B. SPIFFE/SPIRE)
Ersetzt App-Autorisierungneinnein, klärt nur Identität, nicht Berechtigung

TLS und mTLS im Vergleich

TLS 1.2 und 1.3, Versionen und Konfiguration

Aktuell relevant sind zwei Versionen. TLS 1.3 (RFC 8446, 2018) ist der Stand der Technik: schnellerer Handshake (oft eine Round-Trip-Zeit), nur noch starke Cipher Suites und durchgängige Forward Secrecy. TLS 1.2 ist weiterhin verbreitet und gilt bei korrekter Konfiguration als sicher; es sollte für Kompatibilität meist parallel angeboten werden.

Die OWASP-Empfehlungen für die Serverkonfiguration sind eindeutig:

  • TLS 1.0 und 1.1 deaktivieren. Beide sind durch RFC 8996 (März 2021) formell abgekündigt, von PCI DSS verboten und aus allen großen Browsern entfernt. SSLv2 und SSLv3 sind grundsätzlich abzuschalten.
  • Nur starke Cipher Suites mit Forward Secrecy zulassen, schwache und veraltete Verfahren entfernen.
  • Downgrade-Schutz über die TLS_FALLBACK_SCSV-Extension aktivieren, damit Angreifer keine schwächere Version erzwingen.
  • API-Endpunkte sollten HTTP ganz abschalten und nur verschlüsselte Verbindungen annehmen. Ist das nicht möglich, sollten unverschlüsselte Anfragen abgewiesen statt umgeleitet werden, damit keine Daten im Klartext gesendet werden.

Für den deutschsprachigen Raum konkretisiert die BSI TR-02102-2 die zulässigen Protokollversionen, kryptografischen Verfahren und Schlüssellängen; NIST hält die Parallele in SP 800-52 Rev. 2.

Zertifikate, PKI und HSTS

Server-Authentifizierung beruht auf X.509-Zertifikaten und einer Public-Key-Infrastruktur (PKI). Eine Zertifizierungsstelle (CA) signiert das Zertifikat eines Servers; der Client vertraut dem Server, weil er der CA vertraut. Beim Handshake prüft der Client die Signaturkette, die Gültigkeitsdauer und ob der Name (Hostname) zum Zertifikat passt. Wichtig: TLS beweist nur, dass das Gegenüber den privaten Schlüssel zum vorgelegten, gültigen Zertifikat besitzt, nicht dass es sich gutartig verhält.

Eine Restschwäche bleibt: Der erste Aufruf einer Domain kann über unverschlüsseltes HTTP erfolgen und abgefangen werden. HTTP Strict Transport Security (HSTS, RFC 6797) schließt diese Lücke. Über den Antwort-Header weist der Server den Browser an, die Domain künftig ausschließlich über HTTPS aufzurufen:

  • Strict-Transport-Security: max-age=63072000; includeSubDomains erzwingt HTTPS für die Domain und alle Subdomains über zwei Jahre.
  • Die preload-Direktive nimmt die Domain in eine im Browser fest hinterlegte Liste auf, sodass schon der allererste Aufruf verschlüsselt erfolgt. OWASP warnt: preload kann dauerhafte Folgen haben, ein Zurück auf HTTP ist dann kaum noch möglich.

HSTS ist für browserbasierte Clients relevant; reine API-Endpunkte erreichen denselben Effekt, indem sie HTTP gar nicht erst bedienen.

mTLS: beidseitige Authentifizierung

Beim normalen TLS authentifiziert sich nur der Server. Mutual TLS (mTLS) dreht das auf beide Seiten: Auch der Client legt ein Zertifikat vor, und der Server prüft es. Am Ende des Handshakes haben sich beide Parteien kryptografisch ausgewiesen. Damit eignet sich mTLS besonders für Service-zu-Service-Kommunikation, bei der es keinen menschlichen Login gibt: Jeder Dienst erhält eine eigene Identität als Zertifikat.

Typische Einsatzfelder:

  • Interner Ost-West-Verkehr in Microservice-Landschaften, oft über ein Service Mesh, das mTLS zwischen den Diensten transparent erzwingt.
  • Maschine-zu-Maschine-APIs und Partner-Integrationen, wo ein Client-Zertifikat als starke, schwer fälschbare Anmeldung dient, alternativ oder ergänzend zu API-Keys und Tokens.
  • Zero-Trust-Netze, in denen das Netzwerk selbst kein Vertrauen mehr stiftet (vgl. NIST SP 800-207): Jeder Aufruf muss authentifiziert werden, unabhängig davon, ob er aus dem internen Netz kommt.

Auch hier gilt die Abgrenzung aus dem ersten Abschnitt: mTLS beantwortet die Frage wer ruft auf sehr stark, ersetzt aber nicht die fachliche Autorisierung was darf dieser Aufrufer. Identität und Berechtigung bleiben getrennte Schichten.

Zertifikatsrotation und SPIFFE/SVID

Der Engpass von mTLS im Betrieb ist nicht die Kryptografie, sondern das Lifecycle-Management der Zertifikate: ausstellen, verteilen, kurz halten, rechtzeitig erneuern und kompromittierte Zertifikate sperren. Langlebige, manuell verteilte Client-Zertifikate skalieren in dynamischen Umgebungen nicht und führen zu Ausfällen, wenn ein Zertifikat unbemerkt abläuft. Die Antwort sind kurzlebige Zertifikate mit automatischer Rotation: Statt sie zu sperren, lässt man sie schnell verfallen und stellt laufend neue aus.

SPIFFE (Secure Production Identity Framework for Everyone) standardisiert diese Workload-Identität. Kernbausteine:

  • Eine SPIFFE ID ist ein URI der Form spiffe://trust-domain/workload-identifier, zum Beispiel spiffe://acme.com/billing/payments. Sie identifiziert einen Workload eindeutig.
  • Ein SVID (SPIFFE Verifiable Identity Document) ist das Dokument, mit dem ein Workload seine Identität belegt, als X.509-SVID (Zertifikat für mTLS) oder als JWT-SVID (Token). Es gilt als gültig, wenn es von einer Autorität innerhalb der Trust Domain signiert wurde.

Implementierungen wie SPIRE stellen SVIDs automatisch aus und rotieren sie kurzfristig, sodass jeder Dienst seine Identität ohne fest eingebrannte Secrets erhält. SPIFFE wird unter anderem von Istio und Envoy unterstützt und bildet so die Identitätsschicht unter dem mTLS eines Service Mesh.

Gateway-Terminierung und Bezug zum Gateway

In der Praxis wird TLS selten in jedem Backend einzeln gelöst, sondern am Rand terminiert. Ein API Gateway oder Reverse Proxy übernimmt den TLS-Handshake, verwaltet die Zertifikate zentral und entlastet die Dienste dahinter. Bei reiner TLS-Terminierung endet die Verschlüsselung am Gateway, und der Verkehr läuft intern unverschlüsselt weiter. Das ist nur akzeptabel, wenn das interne Netz selbst als vertrauenswürdig gilt, ein Zustand, den Zero Trust ausdrücklich nicht voraussetzt.

Daraus ergeben sich zwei Muster:

  • TLS-Re-Encryption / End-to-End: Das Gateway terminiert die externe Verbindung und baut zum Backend eine neue, eigene TLS- oder mTLS-Verbindung auf. So bleibt auch der Ost-West-Verkehr verschlüsselt und authentifiziert.
  • TLS-Passthrough: Das Gateway reicht den verschlüsselten Strom unverändert durch, das Backend terminiert selbst. Sinnvoll, wenn die Verschlüsselung zwingend bis zum Dienst reichen muss.

Ein Gateway kann zudem als zentrale Durchsetzungsstelle für mTLS am Perimeter dienen, indem es Client-Zertifikate von Partnern prüft. Wie bei jeder Gateway-Kontrolle gilt: Das löst Transport und grobe Authentifizierung, nicht die objektbezogene Autorisierung im Dienst. Sichere APIs brauchen beides, im Sinne von Defense in Depth.

Quellen

Weiterlesen
GrundlagenWas ist ein API Gateway? RisikenBroken Authentication (API2) GrundlagenAPI-Authentifizierung