Was ist Mutual TLS (mTLS)?

Mutual TLS (mTLS) - Definition

Mutual TLS (mTLS) ist eine Erweiterung des Transport Layer Security (TLS)-Protokolls, bei der sich sowohl Server als auch Client gegenseitig mithilfe von X.509-Zertifikaten authentifizieren. Der Kommunikationskanal wird verschlüsselt, und die Identitäten beider Parteien werden innerhalb eines einzigen Protokolls bestätigt. Der Mechanismus ist in den IETF-Standards für TLS 1.2 und TLS 1.3 definiert und nutzt Zertifikatsprofile gemäß RFC 5280.

In TLS 1.3 erfordert der vollständige Handshake (mit Client-Authentifizierung im Handshake) nur 1 RTT (Round-Trip Time) zwischen Client und Server. Dadurch wird die Latenz im Vergleich zum typischen vollständigen TLS‑1.2‑Handshake reduziert, der in der Regel 2 RTT benötigt. Dies wird durch RFC 8446:2018 und RFC 5246:2008 bestätigt.

Im Kontext der Bild- und Videoanonymisierung schützt mTLS Daten während der Übertragung zwischen Verarbeitungskomponenten. Dazu gehören die Übermittlung von Eingabedateien vom Fileserver an das Verarbeitungsmodul, die API-Kommunikation zur Orchestrierung von Aufgaben sowie die Verteilung der Ergebnisse mit unkenntlich gemachten Gesichtern und Kennzeichen. mTLS stellt eine technische Maßnahme zur Sicherstellung von Vertraulichkeit und Integrität der Übertragung gemäß Art. 32 DSGVO dar.

Die Rolle von mTLS bei der Anonymisierung von Fotos und Videos

Die Verarbeitung von Bildern mit Personenabbildungen und Kfz-Kennzeichen betrifft sensible Compliance-Kontexte. Mutual TLS reduziert die Angriffsfläche bei Datenübertragungen entlang der Verarbeitungs- und Automatisierungskette.

• Sichere Kanäle zwischen On-Premise-Knoten - z. B. zwischen AI-Worker und Queue-Server - minimieren das Risiko des Abfangens von Bildframes mit Gesichtern vor der Unkenntlichmachung. Dies gilt insbesondere für lokale Erkennungs- und Verpixelungsverfahren ohne Cloud-Übertragung.
• Authentifizierung technischer Clients - nur autorisierte Dienste dürfen Verarbeitungsaufträge senden und Ergebnisse abrufen. Dies unterstützt die Prinzipien der Datenminimierung und Rechenschaftspflicht.
• Zugriffskontrolle für APIs im Batch-Processing - in Ökosystemen, in denen Scheduler den Anonymisierungsdienst abfragen, kann mTLS Token-basierte Mechanismen ersetzen oder gemäß RFC 8705 ergänzen.

Technologien und Standards für mTLS

Die Implementierung von mTLS basiert auf IETF-Standards, NIST-Richtlinien und bewährten Sicherheitspraktiken. Wesentliche Unterschiede zwischen TLS 1.2 und TLS 1.3 wirken sich auf Sicherheit und Latenz aus.

X.509-Zertifikate müssen RFC 5280 entsprechen. Die Sperrprüfung sollte auf OCSP oder CRL basieren, vorzugsweise mit OCSP Stapling (status_request) gemäß RFC 6066. OCSP ist in RFC 6960 definiert, die Erweiterung „Multiple Certificate Status Request“ in RFC 6961. Die Auswahl von Kurven und Schlüssellängen sollte NIST SP 800-52r2 und SP 800-57 entsprechen - empfohlen werden ECDSA P-256 oder RSA 2048 (mindestens 112 Bit Sicherheit), vorzugsweise mit 128-Bit-Sicherheitsniveau.

Zentrale Parameter und Metriken bei der mTLS-Implementierung

Die Implementierungsparameter bestimmen das Schutzniveau und beeinflussen die Performance der Multimedia-Verarbeitung. Eine normkonforme Auswahl erleichtert Compliance-Audits.

• Protokollversion - TLS 1.3 als Standard gemäß NIST SP 800-52r2 und IETF-Empfehlungen.
• Kryptografische Suites - TLS_AES_128_GCM_SHA256 oder TLS_AES_256_GCM_SHA384; für Systeme ohne AES-Unterstützung: TLS_CHACHA20_POLY1305_SHA256 (RFC 8446).
• Algorithmus und Schlüssellänge - ECDSA P-256 oder P-384, alternativ RSA 2048 oder 3072 (NIST SP 800-57 Pt.1 Rev.5).
• Zertifikatskettenvalidierung - vollständige PKI-Pfadvalidierung gemäß RFC 5280 einschließlich EKU ClientAuth und ServerAuth.
• Sperrprüfung - OCSP Stapling serverseitig und erzwungene Validierung clientseitig (RFC 6066; RFC 6960; RFC 6961).
• Handshake-RTT - 1 RTT in TLS 1.3 reduziert die Latenz bei entfernten Serviceaufrufen (RFC 8446).
• Zertifikatslaufzeiten - kurze Gültigkeitszeiträume gemäß NIST SP 800-57; in der Praxis 90 Tage oder weniger bei automatisierter Rotation.
• CA- oder Public-Key-Pinning - reduziert das Risiko fehlerhafter Zertifikatsausstellungen gemäß Best Practices der Anwendungssicherheit.

Herausforderungen und Einschränkungen von mTLS

Mutual TLS erhöht die Sicherheit der Transportschicht, erfordert jedoch eine ausgereifte PKI-Betriebsführung und fundiertes Protokollverständnis.

• Zertifikatslebenszyklus-Management - Ausstellung, Verteilung, Rotation und Widerruf müssen automatisiert werden. Fehler können zu Ausfällen in der Videoverarbeitung führen.
• Kompatibilität - ältere Client-Bibliotheken unterstützen teilweise weder TLS 1.3 noch OCSP Stapling. Fallback-Strategien sollten ohne Sicherheitsreduktion geplant werden.
• 0-RTT - nicht empfohlen für Anfragen mit Client-Authentifizierung oder Replay-Schutzanforderungen (RFC 8446, Abschnitt 8).
• Kein Schutz ruhender Daten - mTLS ersetzt keine Festplattenverschlüsselung oder lokale Zugriffskontrollen.

Anwendungsbeispiele im Gallio PRO Ökosystem

Gallio PRO wird On-Premise betrieben. Die Software anonymisiert automatisch Gesichter und Kfz-Kennzeichen; weitere Elemente können im Editor manuell unkenntlich gemacht werden. mTLS sichert die Kommunikationskanäle zwischen Komponenten, dient jedoch nicht der Echtzeitverarbeitung, da Gallio PRO keine Streaming-Anonymisierung unterstützt.

• Orchestrierung und Processing-Worker - mTLS beschränkt den Zugriff auf Dienste zur Gesichts- und Kennzeichenverpixelung auf vertrauenswürdige technische Clients.
• Zugriff auf Eingangs- und Ausgangsrepository - Dateiübertragungen mit sensiblen Bilddaten erfolgen über TLS mit Client-Authentifizierung.
• API-Integrationen in automatisierten Prozessen - mTLS kann am API-Gateway gemäß RFC 8705 vorgeschrieben werden und unterstützt die Nachvollziehbarkeit von Aufrufen.
• Compliance-Audit - die Verschlüsselung der Datenübertragung ist eine technische Maßnahme gemäß Art. 32 DSGVO und ISO 27001 und wird im Verzeichnis der Sicherheitsmaßnahmen dokumentiert.

Normative Referenzen und Quellen

Nachfolgend sind zentrale Standards und Dokumente aufgeführt, die Mutual TLS (mTLS) sowie Konfigurationsempfehlungen definieren und technische Aussagen untermauern:

• IETF RFC 8446 - The Transport Layer Security (TLS) 1.3, 2018.
• IETF RFC 5246 - The Transport Layer Security (TLS) 1.2, 2008.
• IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile, 2008.
• IETF RFC 6066 - Transport Layer Security (TLS) Extensions, 2011.
• IETF RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP), 2013.
• IETF RFC 6961 - The TLS Multiple Certificate Status Request Extension, 2013.
• IETF RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, 2020.
• NIST SP 800-52 Rev.2 - Guidelines for the Selection, Configuration, and Use of TLS Implementations, 2019.
• NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management, 2020.
• ENISA - Transport Layer Security (TLS) Deployment Best Practice, 2019.
• DSGVO - Verordnung (EU) 2016/679, Art. 32 Sicherheit der Verarbeitung.