SSL Pinning: Wesen, Mechanismus und Schutz vor MITM-Angriffen

Was ist SSL Pinning?

SSL Pinning ist ein Sicherheitsmechanismus, bei dem eine mobile oder Web-Anwendung ein vertrauenswürdiges Serverzertifikat oder einen öffentlichen Schlüssel speichert und alle Verbindungen ablehnt, deren Zertifikat nicht mit dem gespeicherten übereinstimmt. Im standardmäßigen HTTPS-Schema überprüft der Client das Zertifikat über eine Vertrauenskette bis zur Root-CA — jede CA kann ein Zertifikat für jede Domain signieren. SSL Pinning beseitigt diese Schwachstelle: Anstatt Hunderten von CAs zu vertrauen, vertraut die Anwendung nur einem bestimmten Zertifikat.

Das Problem der Standardprüfung ist, dass jede der Hunderten von Root-CAs ein gültiges Zertifikat für Ihre Domain ausstellen kann — versehentlich oder unter Zwang. Ein Angreifer, der Zugriff auf einen Unternehmensproxy mit eigenem Root-Zertifikat erhält, kann einen MITM-Angriff ohne Browserwarnung durchführen. SSL Pinning schließt diese Sicherheitslücke: Selbst wenn eine CA ein gefälschtes Zertifikat ausstellt, wird die Anwendung es ablehnen, da der Fingerabdruck nicht mit dem aufgezeichneten übereinstimmt.

In mobilen Anwendungen ist SSL Pinning besonders wichtig, da Geräte oft in unsicheren Netzwerken arbeiten — öffentliches Wi-Fi, Unternehmensproxys mit Verkehrsinspektion, infizierte Zugangspunkte. Laut dem Verizon Mobile Security Index (2025) stehen über 60% der Datenlecks in mobilen Anwendungen im Zusammenhang mit dem Abfangen von Datenverkehr auf der Transportschicht.

Warum SSL Pinning in der mobilen Entwicklung notwendig ist

Mobile Anwendungen übertragen sensible Daten — Authentifizierungstoken, Zahlungsinformationen, persönliche Benutzerdaten. Ohne zusätzlichen Schutz kann HTTPS durch Root-Zertifikatsaustausch auf dem Gerät kompromittiert werden — zum Beispiel nach der Installation eines Unternehmensprofils oder einer bösartigen Anwendung. SSL Pinning stellt sicher, dass die Anwendung selbst bei Installation einer gefälschten Root-CA auf dem Gerät weiterhin das Zertifikat gegen ihre eigene Whitelist überprüft.

Wie funktioniert SSL Pinning?

Der SSL Pinning-Prozess besteht aus drei Phasen: Fingerabdruckerfassung, Überprüfung bei der Verbindung und Fehlerbehandlung. Während der Entwicklung erhält der Ingenieur den SHA-256-Fingerabdruck des Serverzertifikats (openssl x509 -fingerprint -sha256) und bettet ihn in den Anwendungscode oder die Konfigurationsdatei ein. Bei jeder HTTPS-Anfrage berechnet die Anwendung den Fingerabdruck des empfangenen Zertifikats und vergleicht ihn mit dem gespeicherten — wenn die Werte nicht übereinstimmen, wird die Verbindung abgebrochen.

Die erste Phase ist das Pinning zur Build-Zeit: Der Entwickler kennt die Serverzertifikate im Voraus und bettet deren Hashes ein. Die zweite Phase ist das Pinning bei der ersten Verbindung (Trust on First Use, TOFU): Die Anwendung merkt sich das Zertifikat bei der ersten Anfrage und verwendet es zur Überprüfung aller folgenden. TOFU ist praktisch für dynamische Umgebungen, aber beim ersten Angriff anfällig — wenn die erste Verbindung bereits abgefangen wird, wird das gefälschte Zertifikat als vertrauenswürdig akzeptiert.

Ein kritisches Detail sind die Backup-Pins. Zertifikate haben ein Ablaufdatum, und wenn sie ersetzt werden, verliert die Anwendung ohne Update die Verbindung zum Server. Ingenieure fügen 2–3 zusätzliche Fingerabdrücke hinzu — zum Beispiel einen Fingerabdruck eines Backup-Zertifikats und einen Fingerabdruck der Root-CA. Wenn sich das Hauptzertifikat ändert, überprüft die Anwendung anhand der Backup-Pins, und die Verbindung funktioniert weiter.

# Abrufen des SHA-256-Zertifikats-Fingerabdrucks
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

Arten von SSL Pinning

Es gibt zwei Hauptansätze zur Implementierung von Pinning: Bindung an das gesamte Zertifikat (Certificate Pinning) und Bindung an den öffentlichen Schlüssel (Public Key Pinning). Jeder Ansatz hat seine eigenen Stärken und Einschränkungen, die sich auf Sicherheit und Wartbarkeit auswirken.

Certificate Pinning

Zertifikats-Pinning ist die strengste Methode. Die Anwendung speichert eine Kopie des vertrauenswürdigen Zertifikats oder seines SHA-256-Fingerabdrucks und vergleicht ihn bei jeder HTTPS-Verbindung mit dem Serverzertifikat. Diese Methode bietet maximale Sicherheit, verursacht jedoch Probleme bei der Rotation — Zertifikate sind normalerweise 1–2 Jahre gültig, danach ist ein erzwungenes Anwendungsupdate erforderlich. Empfohlen für kritische Systeme mit kontrolliertem Update-Zyklus.

Public Key Pinning

Public-Key-Pinning ist ein flexiblerer Ansatz. Anstelle des gesamten Zertifikats merkt sich die Anwendung nur den RSA- oder ECDSA-öffentlichen Schlüssel des Servers. Der Schlüssel kann bei der Neuausstellung des Zertifikats unverändert bleiben, wenn das Unternehmen dasselbe Schlüsselpaar verwendet. Dies reduziert die Häufigkeit von Anwendungsupdates. Wenn der Schlüssel jedoch kompromittiert wird, ist ein kaskadierender Austausch auf allen Clients erforderlich.

SSL Pinning auf iOS

Auf der Apple-Plattform wird SSL Pinning über den URLSession-Delegaten implementiert. Der Entwickler erstellt eine Klasse, die das URLSessionDelegate-Protokoll implementiert, und überschreibt die Methode didReceive challenge, wo er manuell das Serverzertifikat gegen gespeicherte Fingerabdrücke überprüft. Ein alternativer Ansatz ist die Verwendung von Alamofire mit ServerTrustManager, der die Konfiguration vereinfacht.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Im Beispiel erhält der Delegat eine Authentifizierungsanfrage von URLSession, extrahiert serverTrust aus der challenge und vergleicht den SHA-256-Fingerabdruck des Zertifikats mit dem gespeicherten. Bei Übereinstimmung wird die Verbindung fortgesetzt, andernfalls wird die challenge abgelehnt. Für die Produktion lohnt es sich, die Überprüfung mehrerer Backup-Pins und eine Fehlerprotokollierung zur Überwachung hinzuzufügen.

Network Security Config auf iOS

Ab iOS 14 hat Apple integrierte Unterstützung für Certificate Pinning über Info.plist hinzugefügt. Der Entwickler gibt vertrauenswürdige Zertifikate im Schlüssel NSAppTransportSecurity mit dem Unterwörterbuch NSPinnedDomains an. Dieser Ansatz erfordert kein Schreiben von Code, ist aber weniger flexibel — Pins können nicht dynamisch geändert oder Überprüfungsfehler protokolliert werden.

SSL Pinning auf Android

Auf Android gibt es drei Hauptwege zur Implementierung von SSL Pinning: über den CertificatePinner der OkHttp-Bibliothek, über Network Security Config in XML und über benutzerdefinierte Überprüfung in HttpsURLConnection. OkHttp ist der beliebteste und empfohlene Ansatz, der in Retrofit und anderen HTTP-Clients verwendet wird.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // Backup-Pin
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

In der OkHttp-Konfiguration gibt der Entwickler die Domain und einen oder mehrere SHA-256-Fingerabdrücke an. Beim ersten Fingerabdruck vergleicht OkHttp das Serverzertifikat mit den angegebenen Pins. Bei fehlender Übereinstimmung wirft der Client eine SSLPeerUnverifiedException. Ein Backup-Pin ist obligatorisch — ohne ihn werden API-Anfragen bei Zertifikatswechsel sofort fehlschlagen.

Network Security Configuration auf Android

Android unterstützt deklaratives Certificate Pinning über XML-Konfiguration ab API 24. Die Datei res/xml/network_security_config.xml enthält eine Liste von Domains und deren Fingerabdrücke. Diese Methode ist praktisch für statische Konfigurationen, erlaubt jedoch nicht die Implementierung von TOFU oder benutzerdefinierter Überprüfungslogik mit Protokollierung von Anomalien.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Vor- und Nachteile von SSL Pinning

SSL Pinning erhöht die Sicherheit einer mobilen Anwendung erheblich, bringt aber betriebliche Komplexität mit sich. Der Hauptvorteil ist der Schutz vor MITM-Angriffen selbst bei Kompromittierung von Root-CAs. Die Anwendung vertraut nur den vom Entwickler explizit angegebenen Zertifikaten, nicht der gesamten Infrastruktur öffentlicher Zertifizierungsstellen. Dies ist besonders wichtig für Finanzanwendungen, Messenger und Anwendungen mit sensiblen Daten.

Der Hauptnachteil ist die Komplexität der Zertifikatsrotation. Wenn ein Zertifikat abläuft oder widerrufen wird, verlieren Benutzer ohne Anwendungsupdate die Verbindung. Dies wird durch Backup-Pins und einen schrittweisen Aktualisierungsmechanismus gelöst: Die neue Anwendung kennt sowohl alte als auch neue Zertifikate, und nach einer vollständigen Aktualisierung der Benutzer wird der alte Pin aus dem Code entfernt. Es wird empfohlen, mindestens 2 Backup-Pins einzufügen — einen für das aktuelle Zertifikat, einen für die Zukunft.

Ein weiterer Kompromiss ist die Unmöglichkeit, öffentliche Proxies zur Verkehrsdebuggung (Charles Proxy, Burp Suite) ohne Deaktivierung des Pinnings zu verwenden. Dies erschwert die Debugging von Netzwerkanfragen während der Entwicklung. Die Lösung ist eine bedingte Kompilierung: Pinning ist in Debug-Builds deaktiviert, in Release-Builds aktiviert. OWASP empfiehlt die Verwendung des BuildConfig.DEBUG-Flags zum Umschalten.