SSL Pinning

SSL Pinning ist ein Sicherheitsmechanismus, bei dem eine Client-Anwendung das erwartete kryptografische Zertifikat oder den öffentlichen Schlüssel eines Servers fest codiert oder "pinnt", wodurch Verbindungen fehlschlagen, wenn ein Proxy versucht, den Datenverkehr mit einem anderen, selbst wenn gültigen, Zertifikat abzufangen. Dieser Prozess erhöht die Sicherheit, indem er Man-in-the-Middle (MITM)-Angriffe verhindert, die auf der Präsentation eines vertrauenswürdigen, aber unerwarteten Zertifikats basieren.

Wie SSL Pinning funktioniert

SSL Pinning arbeitet auf der Client-Seite und erweitert den standardmäßigen TLS-Handshake-Validierungsprozess. Typischerweise überprüft der Client während eines TLS-Handshakes das Server-Zertifikat anhand seines Trust Stores (einer Sammlung vertrauenswürdiger Root-Zertifizierungsstellen). Wenn eine CA im Trust Store das Server-Zertifikat signiert hat, wird die Verbindung fortgesetzt.

Mit SSL Pinning speichert die Client-Anwendung einen spezifischen Bezeichner – entweder das vollständige Zertifikat oder seinen öffentlichen Schlüssel – für den erwarteten Server. Wenn eine Verbindung initiiert wird:
1. Der Server präsentiert sein Zertifikat.
2. Der Client führt die standardmäßige Vertrauenskette-Validierung unter Verwendung seines CA Trust Stores durch.
3. Zusätzlich vergleicht der Client das präsentierte Zertifikat oder den öffentlichen Schlüssel des Servers mit seinem vorab gepinnten Wert.
4. Wenn beide Validierungen erfolgreich sind (vertrauenswürdige CA und gepinnter Wert stimmen überein), wird die Verbindung fortgesetzt.
5. Wenn der gepinnte Wert nicht übereinstimmt, selbst wenn das Zertifikat von einer vertrauenswürdigen CA signiert ist, wird die Verbindung sofort mit einem Validierungsfehler beendet.

Diese zusätzliche Überprüfung erschwert es einem Angreifer, selbst einem, der eine vertrauenswürdige CA kompromittiert hat, erheblich, den Datenverkehr abzufangen.

Arten von SSL Pinning

Es gibt zwei primäre Arten von SSL Pinning:

• Zertifikat-Pinning: Der Client pinnt das exakte X.509-Zertifikat des Servers. Diese Methode ist hochspezifisch, erfordert jedoch eine Aktualisierung der Anwendung, wann immer das Server-Zertifikat erneuert oder geändert wird.
• Public Key Pinning: Der Client pinnt den öffentlichen Schlüssel, der aus dem Server-Zertifikat extrahiert wurde. Dies bietet mehr Flexibilität als das Zertifikat-Pinning, da der öffentliche Schlüssel im Allgemeinen konstant bleibt, selbst wenn das Zertifikat selbst erneuert wird (solange das Schlüsselpaar sich nicht ändert). Dies wird oft durch das Pinnen des Subject Public Key Info (SPKI)-Hashs implementiert.

Beispiel: Konzeptionelles Android Pinning (Java)

import okhttp3.CertificatePinner;
import okhttp3.OkHttpClient;
import okhttp3.Request;

public class PinnedHttpClient {

    public static void main(String[] args) throws Exception {
        // Example SHA256 hash of a public key.
        // In a real application, this would be derived from the target server's certificate.
        String hostname = "api.example.com";
        String sha256_publicKey_hash = "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="; // Replace with actual hash

        CertificatePinner certificatePinner = new CertificatePinner.Builder()
                .add(hostname, sha256_publicKey_hash)
                .build();

        OkHttpClient client = new OkHttpClient.Builder()
                .certificatePinner(certificatePinner)
                .build();

        Request request = new Request.Builder()
                .url("https://" + hostname + "/data")
                .build();

        // This call will fail if the server's public key does not match the pinned hash,
        // even if the certificate is signed by a trusted CA.
        try {
            client.newCall(request).execute();
            System.out.println("Connection successful (or would be if executed)");
        } catch (javax.net.ssl.SSLPeerUnverifiedException e) {
            System.err.println("SSL Pinning failed: " + e.getMessage());
        }
    }
}

Warum Anwendungen SSL Pinning verwenden

Anwendungen, insbesondere mobile und IoT-Anwendungen, implementieren SSL Pinning aus mehreren kritischen Sicherheitsgründen:

• Schutz vor betrügerischen Zertifizierungsstellen (CAs): Standard-TLS basiert auf der Integrität aller CAs im Trust Store des Clients. Wenn eine CA kompromittiert wird oder ein betrügerisches Zertifikat für eine Domäne ausstellt, könnte ein Angreifer dies für einen MITM-Angriff nutzen. SSL Pinning umgeht diese Schwachstelle, indem es explizit nur einem spezifischen Zertifikat oder öffentlichen Schlüssel vertraut, unabhängig von anderen vertrauenswürdigen CAs.
• Minderung der Manipulation des Trust Stores: Auf benutzergesteuerten Geräten könnte ein Benutzer oder Malware zusätzliche Root-Zertifikate in den Trust Store des Geräts installieren. Obwohl dies oft für legitimes Debugging geschieht, kann es auch ausgenutzt werden. SSL Pinning stellt sicher, dass selbst wenn eine bösartige Root-CA hinzugefügt wird, die Anwendung Verbindungen zu ihren gepinnten Domänen weiterhin ablehnt, wenn das präsentierte Zertifikat nicht mit dem Pin übereinstimmt.
• Erhöhte Sicherheit für sensible Daten: Anwendungen, die hochsensible Daten (z.B. Bankdaten, Gesundheitsdaten, Authentifizierungs-Tokens) verarbeiten, verwenden Pinning, um ein höheres Maß an Vertrauen zu etablieren und die Angriffsfläche für Netzwerkabfang zu reduzieren.

Wie SSL Pinning Proxys beeinflusst

Proxys, insbesondere solche, die für die Verkehrsinspektion, das Debugging oder die Sicherheitsscans entwickelt wurden, fungieren als Vermittler (ein legitimer MITM).

Wenn eine Anwendung einen Proxy für eine HTTPS-Verbindung verwendet:
1. Der Client verbindet sich mit dem Proxy.
2. Der Proxy stellt seine eigene Verbindung zum Zielserver her.
3. Der Proxy generiert dann ein neues, spontanes Zertifikat für den Zielserver, signiert von seiner eigenen Root-CA (die vom Client vertraut werden muss, damit der Proxy funktioniert).
4. Der Proxy präsentiert dieses neu generierte Zertifikat dem Client.

Dieser Prozess ist grundsätzlich inkompatibel mit SSL Pinning. Die Client-Anwendung erwartet das ursprüngliche Zertifikat oder den öffentlichen Schlüssel des Servers. Wenn der Proxy sein eigenes generiertes Zertifikat präsentiert, selbst wenn es von einer vom Betriebssystem vertrauten CA signiert ist, erkennt der SSL Pinning-Mechanismus des Clients eine Nichtübereinstimmung mit seinem fest codierten Pin. Folglich beendet der Client die Verbindung mit einer SSLPeerUnverifiedException oder einem ähnlichen Fehler, wodurch der Proxy daran gehindert wird, den Datenverkehr abzufangen und zu inspizieren.

• Transparente Proxys: Diese Proxys fangen den Datenverkehr ohne explizite Client-Konfiguration ab. Wenn die Client-Anwendung SSL Pinning aktiviert hat, erkennt sie dennoch das Zertifikat des Proxys und beendet die Verbindung, selbst wenn das Betriebssystem der Root-CA des Proxys vertraut.
• Abfangende Proxys (Explizit): Wenn ein Client explizit für die Verwendung eines Proxys konfiguriert ist, kollidiert das Zertifikat des Proxys dennoch mit dem gepinnten Zertifikat der Anwendung, was zu Verbindungsfehlern führt.

Auswirkungen auf den Betrieb

• Debugging und Entwicklung: Entwickler verwenden oft Proxys (z.B. Burp Suite, Fiddler, Charles Proxy), um den Netzwerkverkehr für Debugging, API-Entwicklung und Leistungsanalyse zu inspizieren. SSL Pinning behindert dies direkt und macht es unmöglich, die Netzwerkanfragen und -antworten der Anwendung zu sehen.
• Sicherheitstests: Penetrationstester verlassen sich auf Proxys, um Anwendungs-Schwachstellen zu analysieren, einschließlich API-Missbrauch, Datenlecks und Authentifizierungsfehler. SSL Pinning verhindert, dass diese Tools korrekt funktionieren, und behindert umfassende Sicherheitsbewertungen.
• Monitoring und Analysen: Einige Unternehmensumgebungen verwenden Proxys für Netzwerküberwachung, Data Loss Prevention (DLP) oder Analysen. Anwendungen mit SSL Pinning umgehen oder blockieren diese Überwachungsfunktionen.

Umgehen von SSL Pinning (für legitime Zwecke)

Das Umgehen von SSL Pinning wird im Allgemeinen für legitime Zwecke wie Sicherheitstests, Debugging oder Reverse Engineering durchgeführt und erfolgt typischerweise in kontrollierten Umgebungen. Es erfordert eine Modifikation der Client-Anwendung oder ihrer Ausführungsumgebung.

• Ändern des Anwendungscodes: Wenn der Quellcode verfügbar ist, können Entwickler die Pinning-Logik für Test-Builds entfernen oder deaktivieren. Dies ist die zuverlässigste Methode.
• Laufzeit-Instrumentierungs-Frameworks: Tools wie Frida oder Xposed ermöglichen die dynamische Modifikation des Anwendungsverhaltens zur Laufzeit. Diese Frameworks können sich in die SSL/TLS-Bibliotheksaufrufe der Anwendung einklinken und die Pinning-Prüfungen umgehen. Dies erfordert oft ein gerootetes oder jailbroken Gerät.
  ```javascript
  // Example Frida script snippet to bypass Android SSL Pinning (conceptual)
  Java.perform(function () {
  var CertificateFactory = Java.use("java.security.cert.CertificateFactory");
  var FileInputStream = Java.use("java.io.FileInputStream");
  var BufferedInputStream = Java.use("java.io.BufferedInputStream");
  var X509Certificate = Java.use("java.security.cert.X509Certificate");
  var KeyStore = Java.use("java.security.KeyStore");
  var TrustManagerFactory = Java.use("javax.net.ssl.TrustManagerFactory");
  var SSLContext = Java.use("javax.net.ssl.SSLContext");

  // TrustManagerImpl.checkTrustedRecursive is often targeted
  var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
  TrustManagerImpl.checkTrustedRecursive.implementation = function (a, b, c, d, e, f) {
      // Bypass the actual check, effectively trusting all certificates
      return Java.array('java.security.cert.X509Certificate', []);
  };
  
  // ... other hooks for various SSL libraries (OkHttp, Apache, etc.)
  

  });
  ```
  * Modifizieren von Anwendungsbinärdateien: Für Anwendungen, bei denen der Quellcode nicht verfügbar ist, können Reverse-Engineering-Tools verwendet werden, um die kompilierte Binärdatei zu patchen, um das Pinning zu deaktivieren. Dies ist komplex und erfordert erhebliche Fachkenntnisse.
  * Proxy-bewusste Client-Konfiguration: Einige Anwendungen bieten möglicherweise Konfigurationsoptionen an, um benutzerdefinierte CAs zu vertrauen oder das Pinning in Entwicklungsmodi zu deaktivieren, obwohl dies bei Produktionsanwendungen selten ist.

Das Umgehen von SSL Pinning sollte verantwortungsvoll und ethisch erfolgen, hauptsächlich für Sicherheitsforschung, Entwicklung oder autorisierte Tests. Das unbefugte Umgehen für böswillige Zwecke ist illegal und unethisch.