SSL Pinning: innebörd, mekanism och skydd mot MITM-attacker

Vad är SSL Pinning?

SSL Pinning — är en säkerhetsmekanism där en mobil eller webbapp kommer ihåg ett betrott certifikat eller offentlig nyckel från servern och avvisar alla anslutningar vars certifikat inte matchar det lagrade. I standardschemat för HTTPS verifierar klienten certifikatet via förtroendekedjan upp till rot-CA — vilken CA som helst kan signera ett certifikat för vilken domän som helst. SSL Pinning eliminerar denna svaghet: istället för att lita på hundratals CA:er litar appen bara på ett specifikt certifikat.

Problemet med standardverifiering är att vilken som helst av de hundratals rot-CA:erna kan utfärda ett giltigt certifikat för din domän — av misstag eller under tvång. En angripare som får tillgång till en företagsproxy med eget rotcertifikat kan utföra en MITM-attack utan webbläsarvarning. SSL Pinning täpper till denna sårbarhet: även om en CA utfärdar ett förfalskat certifikat kommer appen att avvisa det eftersom fingeravtrycket inte matchar det registrerade.

I mobila appar är SSL Pinning särskilt viktigt eftersom enheter ofta arbetar i osäkra nätverk — offentligt Wi-Fi, företagsproxyer med trafikinspektion, infekterade åtkomstpunkter. Enligt Verizon Mobile Security Index (2025) är över 60% av dataläckorna i mobila appar kopplade till avlyssning av trafik på transportnivå.

Varför SSL Pinning behövs i mobilutveckling

Mobila appar överför känslig data — autentiseringstoken, betalningsinformation, användarnas personuppgifter. Utan extra skydd kan HTTPS äventyras genom ersättning av rotcertifikatet på enheten — till exempel efter installation av en företagsprofil eller skadlig app. SSL Pinning garanterar att även om en förfalskad rot-CA är installerad på enheten, kommer appen att fortsätta verifiera certifikatet enligt sin egen vitlista.

Hur fungerar SSL Pinning?

SSL Pinning-processen består av tre steg: att få fingeravtryck, verifiering vid anslutning och felhantering. I utvecklingsfasen får ingenjören SHA-256-fingeravtrycket för serverns certifikat (openssl x509 -fingerprint -sha256) och bäddar in det i appkoden eller konfigurationsfilen. Vid varje HTTPS-förfrågan beräknar appen fingeravtrycket för det mottagna certifikatet och jämför det med det lagrade — om värdena inte matchar bryts anslutningen.

Första steget — pinning i byggfasen: utvecklaren känner till serverns certifikat i förväg och bäddar in deras hashvärden. Andra steget — pinning vid första anslutningen (trust on first use, TOFU): appen kommer ihåg certifikatet vid den första förfrågan och använder det för att verifiera alla efterföljande. TOFU är bekvämt för dynamiska miljöer men är sårbart vid första attacken — om den första anslutningen redan är avlyssnad kommer det förfalskade certifikatet att accepteras som betrott.

Kritisk detalj — reservfingeravtryck (backup pins). Certifikat har en giltighetstid och när de byts ut förlorar den ouppdaterade appen anslutningen till servern. Ingenjörer lägger till 2–3 extra fingeravtryck — till exempel fingeravtrycket för reservcertifikatet och fingeravtrycket för rot-CA. Om huvudcertifikatet ändras verifierar appen enligt backup pins och anslutningen fortsätter att fungera.

# Hämta SHA-256-fingeravtryck för certifikatet
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

Typer av SSL Pinning

Det finns två huvudsakliga angreppssätt för att implementera pinning: bindning till hela certifikatet (certificate pinning) och bindning till den publika nyckeln (public key pinning). Varje angreppssätt har sina styrkor och begränsningar som påverkar säkerheten och underhållsvänligheten.

Certificate Pinning

Bindning till certifikat — den strängaste metoden. Appen lagrar en kopia av det betrodda certifikatet eller dess SHA-256-fingeravtryck och jämför med serverns certifikat vid varje HTTPS-anslutning. Denna metod ger maximal säkerhet men skapar problem vid rotation — certifikat är vanligtvis giltiga i 1–2 år, varefter en tvångsuppdatering av appen krävs. Rekommenderas för kritiska system med kontrollerad uppdateringscykel.

Public Key Pinning

Fixering av publik nyckel — ett mer flexibelt angreppssätt. Istället för hela certifikatet kommer appen bara ihåg serverns RSA- eller ECDSA-publika nyckel. Nyckeln kan förbli oförändrad vid återutgivning av certifikatet om företaget använder samma nyckelpar. Detta minskar frekvensen av appuppdateringar. Men om nyckeln komprometteras kommer en kaskadersättning hos alla klienter att krävas.

SSL Pinning på iOS

På Apple-plattformen implementeras SSL Pinning via URLSession-delegaten. Utvecklaren skapar en klass som implementerar URLSessionDelegate-protokollet och åsidosätter metoden didReceive challenge, där den manuellt verifierar serverns certifikat mot lagrade fingeravtryck. Ett alternativt angreppssätt — användning av Alamofire med ServerTrustManager, som förenklar konfigurationen.

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

I exemplet tar delegaten emot en autentiseringsförfrågan från URLSession, extraherar serverTrust från challenge och jämför SHA-256-fingeravtrycket för certifikatet med det lagrade. Om fingeravtrycket matchar — fortsätter anslutningen, annars avvisas challenge. För produktion är det värt att lägga till kontroll av flera backup pins och loggning av fel för övervakning.

Network Security Config på iOS

Från och med iOS 14 lade Apple till inbyggt stöd för Certificate Pinning via Info.plist. Utvecklaren anger betrodda certifikat i nyckeln NSAppTransportSecurity med underordboken NSPinnedDomains. Detta angreppssätt kräver ingen kodning men är mindre flexibelt — pins kan inte ändras dynamiskt eller verifieringsfel loggas.

SSL Pinning på Android

På Android finns det tre huvudsakliga sätt att implementera SSL Pinning: via CertificatePinner från OkHttp-biblioteket, via Network Security Config i XML och via anpassad verifiering i HttpsURLConnection. OkHttp — det mest populära och rekommenderade angreppssättet, som används i Retrofit och andra HTTP-klienter.

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

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

I OkHttp-konfigurationen anger utvecklaren domänen och en eller flera SHA-256-fingeravtryck. Vid det första fingeravtrycket jämför OkHttp serverns certifikat med de angivna pinnarna. Om det inte finns någon matchning kastar klienten SSLPeerUnverifiedException. Reservpin är obligatorisk — utan den kommer API-förfrågningar att omedelbart börja misslyckas vid certifikatändring.

Network Security Configuration på Android

Android stöder deklarativ Certificate Pinning via XML-konfiguration från API 24. Filen res/xml/network_security_config.xml innehåller en lista över domäner och deras fingeravtryck. Denna metod är bekväm för statiska konfigurationer men tillåter inte implementering av TOFU eller anpassad verifieringslogik med loggning av avvikelser.

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

Fördelar och nackdelar med SSL Pinning

SSL Pinning ökar säkerheten för mobila appar avsevärt men medför operativ komplexitet. Den största fördelen — skydd mot MITM-attacker även vid kompromettering av rot-CA:er. Appen litar bara på certifikat som uttryckligen anges av utvecklaren, inte på hela infrastrukturen av offentliga certifikatutfärdare. Detta är särskilt kritiskt för finansiella appar, meddelandetjänster och appar med känslig data.

Den största nackdelen — komplexiteten i certifikatrotation. Om ett certifikat löper ut eller återkallas förlorar användare utan appuppdatering anslutningen. Detta löses via reservpinnar och en mekanism för gradvis uppdatering: den nya appen känner till det gamla och nya certifikatet, och efter fullständig uppdatering av användarna tas den gamla pinn bort från koden. Det rekommenderas att inkludera minst 2 backup pins — en för det aktuella certifikatet, en för det framtida.

En annan kompromiss — omöjligheten att använda offentliga proxyer för trafikfelsökning (Charles Proxy, Burp Suite) utan att inaktivera pinning. Detta försvårar felsökning av nätverksförfrågningar i utvecklingsfasen. Lösning — villkorlig kompilering: i debug-bygge är pinning avstängd, i release-bygge påslagen. OWASP rekommenderar att använda flaggan BuildConfig.DEBUG för växling.