SSL Pinning: essentie, mechanisme en bescherming tegen MITM-aanvallen

Wat is SSL Pinning?

SSL Pinning — is een beveiligingsmechanisme waarbij een mobiele of webapp een vertrouwd certificaat of publieke sleutel van de server onthoudt en elke verbinding waarvan het certificaat niet overeenkomt met de opgeslagene weigert. In het standaard HTTPS-schema verifieert de client het certificaat via de vertrouwensketen tot aan de root-CA — elke CA kan een certificaat voor elk domein ondertekenen. SSL Pinning elimineert deze zwakte: in plaats van honderden CA's te vertrouwen, vertrouwt de app slechts één specifiek certificaat.

Het probleem van standaardverificatie is dat elk van de honderden root-CA's een geldig certificaat voor uw domein kan uitgeven — per ongeluk of onder dwang. Een aanvaller die toegang krijgt tot een bedrijfsproxy met een eigen root-certificaat, kan een MITM-aanval uitvoeren zonder browserwaarschuwing. SSL Pinning sluit deze kwetsbaarheid: zelfs als een CA een vervangen certificaat uitgeeft, wijst de app dit af omdat de vingerafdruk niet overeenkomt met de opgeslagen.

In mobiele apps is SSL Pinning vooral belangrijk omdat apparaten vaak werken in onbeveiligde netwerken — openbare Wi-Fi, bedrijfsproxy's met verkeersinspectie, geïnfecteerde toegangspunten. Volgens de Verizon Mobile Security Index (2025) houdt meer dan 60% van de datalekken in mobiele apps verband met het onderscheppen van verkeer op transportniveau.

Waarom SSL Pinning nodig is in mobiele ontwikkeling

Mobiele apps verzenden gevoelige gegevens — authenticatietokens, betalingsinformatie, persoonlijke gegevens van gebruikers. Zonder extra beveiliging kan HTTPS worden gecompromitteerd door vervanging van het root-certificaat op het apparaat — bijvoorbeeld na installatie van een bedrijfsprofiel of kwaadaardige app. SSL Pinning garandeert dat, zelfs als er een vervangen root-CA op het apparaat is geïnstalleerd, de app het certificaat blijft verifiëren volgens zijn eigen witte lijst.

Hoe werkt SSL Pinning?

Het SSL Pinning-proces bestaat uit drie fasen: het verkrijgen van de vingerafdruk, verificatie bij verbinding en foutafhandeling. In de ontwikkelfase verkrijgt de ontwikkelaar de SHA-256 vingerafdruk van het servercertificaat (openssl x509 -fingerprint -sha256) en slaat deze op in de app-code of het configuratiebestand. Bij elk HTTPS-verzoek berekent de app de vingerafdruk van het ontvangen certificaat en vergelijkt deze met de opgeslagen — als de waarden niet overeenkomen, wordt de verbinding verbroken.

Eerste fase — pinning in de bouwfase: de ontwikkelaar kent de servercertificaten van tevoren en slaat hun hashes op. Tweede fase — pinning bij de eerste verbinding (trust on first use, TOFU): de app onthoudt het certificaat bij het eerste verzoek en gebruikt dit voor verificatie van alle volgende. TOFU is handig voor dynamische omgevingen, maar kwetsbaar bij de eerste aanval — als de eerste verbinding al is onderschept, wordt het vervangen certificaat als vertrouwd geaccepteerd.

Kritiek detail — back-uppingsafdrukken (backup pins). Certificaten hebben een geldigheidsduur en bij vervanging verliest de niet-bijgewerkte app de verbinding met de server. Ontwikkelaars voegen 2–3 extra vingerafdrukken toe — bijvoorbeeld de vingerafdruk van het back-upcertificaat en de vingerafdruk van de root-CA. Als het hoofdcertificaat verandert, controleert de app via backup pins en blijft de verbinding werken.

# Verkrijgen van SHA-256 vingerafdruk van certificaat
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

Soorten SSL Pinning

Er zijn twee hoofdbenaderingen voor het implementeren van pinning: binding aan het volledige certificaat (certificate pinning) en binding aan de publieke sleutel (public key pinning). Elke benadering heeft zijn sterke punten en beperkingen die de beveiliging en onderhoudsgemak beïnvloeden.

Certificate Pinning

Binding aan certificaat — de strengste methode. De app slaat een kopie van het vertrouwde certificaat of de SHA-256 vingerafdruk op en vergelijkt deze bij elke HTTPS-verbinding met het servercertificaat. Deze methode biedt maximale beveiliging, maar creëert problemen bij rotatie — certificaten zijn meestal 1–2 jaar geldig, waarna een geforceerde app-update vereist is. Aanbevolen voor kritieke systemen met een gecontroleerde updatecyclus.

Public Key Pinning

Fixatie van de publieke sleutel — een flexibelere benadering. In plaats van het hele certificaat onthoudt de app alleen de RSA- of ECDSA-publieke sleutel van de server. De sleutel kan onveranderd blijven bij heruitgifte van het certificaat, als het bedrijf hetzelfde sleutelpaar gebruikt. Dit vermindert de frequentie van app-updates. Echter, als de sleutel wordt gecompromitteerd, is een cascadewijziging bij alle clients vereist.

SSL Pinning op iOS

Op het Apple-platform wordt SSL Pinning geïmplementeerd via de URLSession-delegate. De ontwikkelaar maakt een klasse die het URLSessionDelegate-protocol implementeert en overschrijft de methode didReceive challenge, waar handmatig het servercertificaat wordt gecontroleerd tegen opgeslagen vingerafdrukken. Een alternatieve benadering — gebruik van Alamofire met ServerTrustManager, die de configuratie vereenvoudigt.

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)
        }
    }
}

In het voorbeeld ontvangt de delegate een authenticatieverzoek van URLSession, haalt serverTrust uit de challenge en vergelijkt de SHA-256 vingerafdruk van het certificaat met de opgeslagen. Als de vingerafdruk overeenkomt — wordt de verbinding voortgezet, anders wordt de challenge afgewezen. Voor productie is het aan te raden om meerdere backup pins-controles en foutregistratie voor monitoring toe te voegen.

Network Security Config op iOS

Vanaf iOS 14 heeft Apple ingebouwde ondersteuning voor Certificate Pinning via Info.plist toegevoegd. De ontwikkelaar geeft vertrouwde certificaten op in de sleutel NSAppTransportSecurity met subwoordenboek NSPinnedDomains. Deze benadering vereist geen codering, maar is minder flexibel — pins kunnen niet dynamisch worden gewijzigd of verificatiefouten worden geregistreerd.

SSL Pinning op Android

Op Android zijn er drie belangrijke manieren om SSL Pinning te implementeren: via CertificatePinner van de OkHttp-bibliotheek, via Network Security Config in XML en via aangepaste controle in HttpsURLConnection. OkHttp — de meest populaire en aanbevolen benadering, gebruikt in Retrofit en andere HTTP-clients.

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

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

In de OkHttp-configuratie geeft de ontwikkelaar het domein en een of meerdere SHA-256 vingerafdrukken op. Bij de eerste vingerafdruk vergelijkt OkHttp het servercertificaat met de opgegeven pins. Als er geen overeenkomst is, gooit de client een SSLPeerUnverifiedException. Backup pin is verplicht — zonder dit zullen API-verzoeken bij certificaatwijziging direct mislukken.

Network Security Configuration op Android

Android ondersteunt declaratieve Certificate Pinning via XML-configuratie vanaf API 24. Het bestand res/xml/network_security_config.xml bevat een lijst van domeinen en hun vingerafdrukken. Deze methode is handig voor statische configuraties, maar maakt het niet mogelijk om TOFU of aangepaste verificatielogica met registratie van afwijkingen te implementeren.

<!-- 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>

Voor- en nadelen van SSL Pinning

SSL Pinning verhoogt de beveiliging van de mobiele app aanzienlijk, maar brengt operationele complexiteit met zich mee. Het belangrijkste voordeel — bescherming tegen MITM-aanvallen, zelfs bij compromittering van root-CA's. De app vertrouwt alleen certificaten die expliciet door de ontwikkelaar zijn opgegeven, niet de hele infrastructuur van openbare certificeringsinstanties. Dit is vooral kritiek voor financiële apps, berichtenapps en apps met gevoelige gegevens.

Het belangrijkste nadeel — de complexiteit van certificaatrotatie. Als een certificaat verloopt of wordt ingetrokken, verliezen gebruikers zonder app-update de verbinding. Dit wordt opgelost via backup pins en een mechanisme voor geleidelijke update: de nieuwe app kent het oude en nieuwe certificaat, en na volledige update van gebruikers wordt de oude pin uit de code verwijderd. Het is aan te raden om minimaal 2 backup pins te gebruiken — één voor het huidige certificaat, één voor de toekomstige.

Een ander compromis — de onmogelijkheid om openbare proxy's te gebruiken voor verkeersdebugging (Charles Proxy, Burp Suite) zonder pinning uit te schakelen. Dit bemoeilijkt debugging van netwerkverzoeken in de ontwikkelfase. Oplossing — conditionele compilatie: in debug-build is pinning uitgeschakeld, in release-build ingeschakeld. OWASP beveelt het gebruik van de BuildConfig.DEBUG-vlag aan voor het schakelen.