TLS Client Zertifikate verstehen

TLS Verschlüsselung kommt im Alltag fast überall zum Einsatz. Als normaler Nutzer bekommt man davon nur wenig mit. Die Abläufe des Protokolls sind jedoch sehr umfangreich, und es kann nicht schaden, sich einmal anzuschauen, was Client und Server da im Hintergrund eigentlich machen.

Ein normaler TLS-Handshake zum Aufbau einer sicheren Verbindung läuft in der Regel so ab:

  1. Client Hello: Der Client (z. B. ein Webbrowser) sendet eine Nachricht an den Server, die die unterstützten TLS-Versionen, Verschlüsselungsmethoden und eine Zufallszahl enthält.
  2. Server Hello: Der Server antwortet mit seiner Auswahl an Verschlüsselungsmethoden und sendet ebenfalls eine Zufallszahl sowie sein digitales Zertifikat, das seine Identität bestätigt (inklusive Public Key).
  3. Server Certificate Verification durch den Client: Der Client überprüft das Zertifikat des Servers auf Gültigkeit und Authentizität, in der Regel durch ein lokal installiertes Zertifikat einer Zertifizierungsstelle (CA).
  4. Client Key Exchange: Der Client generiert einen „Pre-Master Secret“ (eine weitere Zufallszahl) und verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers. Dieses „Pre-Master Secret“ wird zum Server gesendet.
  5. Session Key Generation: Beide Seiten (Client und Server) verwenden die Zufallszahlen und das „Pre-Master Secret“, um denselben „Session Key“ zu erzeugen, der für die Verschlüsselung und Entschlüsselung der Daten genutzt wird.
  6. Finished Messages: Der Client und der Server senden jeweils eine „Finished“-Nachricht, um zu bestätigen, dass der Handshake abgeschlossen ist und die Schlüssel erfolgreich ausgetauscht wurden.
  7. Sichere Verbindung: Der Handshake ist abgeschlossen, und die Datenübertragung erfolgt nun verschlüsselt mit dem gemeinsamen Session Key.

Sofern der Server aber so konfiguriert ist, dass auch Client Zertifikate (mTLS, Mutual TLS) erforderlich sind, ändert sich dieser Ablauf leicht. Die gleich bleibenden Schritte werden im Folgenden nicht nochmal erläutert:

  1. Client Hello
  2. Server Hello
  3. NEU: Certificate Request: Zusätzlich fordert der Server nun ein Client-Zertifikat an, um den Client zu authentifizieren.
  4. Server Certificate Verification durch den Client
  5. NEU: Client Certificate: Der Client sendet sein eigenes Zertifikat an den Server, damit dieser den Client authentifizieren kann. Auch der Public Key des Clients wird zum Server gesendet.
  6. NEU: Client Certificate Verification durch den Server: Der Server überprüft das Zertifikat des Clients auf Gültigkeit und Authentizität durch die konfigurierte CA.
  7. Client Key Exchange
  8. Session Key Generation
  9. Finished Messages
  10. Sichere Verbindung

Vor- und Nachteile von mTLS

Dadurch, dass sowohl Client und Server sich gegenseitig authentifizieren müssen, wird mit mTLS das sogenannte Zero Trust Networking möglich. Eine Kommunikation ist damit gegen die gängigen Angriffe wie Man-in-the-middle, Replay oder Spoffing abgesichert.

Nachteilig ist natürlich der deutlich höhere Konfigurationsaufwand, da die Zertifikate im Vorfeld über ein sicheres Verfahren auf den Clients ausgerollt werden müssen, und auch regelmäßig rotiert werden sollten.

Konfigurationsbeispiel

Beispiel einer Client Zertifikat Konfiguration in nginx:

server {
    listen 443 ssl;
    server_name example.com;

    # SSL-Zertifikat und Schlüssel des Servers
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Zertifizierungsstelle (CA), die Client-Zertifikate validiert
    ssl_client_certificate /etc/nginx/ssl/ca.crt;

    # Aktivierung der Client-Zertifikatprüfung
    ssl_verify_client on;

    location / {
        # Beispiel-Inhalt, um erfolgreiche Verbindung zu bestätigen
        return 200 "Hello, your client certificate has been verified!";
    }

    # Fehlerseite, falls kein gültiges Client-Zertifikat vorliegt
    error_page 495 /no_cert.html;

    location = /no_cert.html {
        return 403 "Client certificate required!";
    }
}

Antworten