Certificate Pinning: co to je, metody připoutání certifikátů a jak implementovat

Výhody a nevýhody Certificate Pinning

Certificate Pinning výrazně zvyšuje bezpečnost mobilní aplikace, ale klade provozní zátěž na vývojový tým. Je důležité zvážit výhody ochrany a riziko blokování spojení při nesprávné implementaci.

Hlavní výhoda — ochrana před útoky Man-in-the-Middle, včetně případů kompromitace CA. Pinning činí nepoužitelnými falešné certifikáty vydané útočníkem: i když CA podepsal padělek, aplikace jej odmítne. Další výhoda — ochrana proti podnikovým proxy serverům, které nahrazují certifikáty pro kontrolu provozu. Podle Google Security Blog (2023) mají aplikace s pinning o 86% nižší šanci na prolomení prostřednictvím zachycení provozu ve srovnání s aplikacemi používajícími pouze standardní TLS ověření.

Hlavní nevýhoda pinning — riziko samoblokování: pokud se certifikát serveru změní (prodloužení, změna poskytovatele, rotace klíčů) před vydáním aktualizace aplikace, uživatelé ztratí přístup k serveru. Další nevýhody: obtížnost ladění (při každé změně nastavení je třeba aktualizovat piny), zvýšení velikosti APK o 5–15 KB při použití TrustKit a nemožnost rychlého vrácení změn bez nové verze. Pro minimalizaci rizik se používají záložní piny, automatická rotace každých 2–3 měsíce a období milosti (grace period), kdy aplikace přijímá starý i nový certifikát. Je také třeba mít na paměti, že při zapnutém pinning během vývoje nelze používat proxy nástroje (Burp Suite, Charles) pro ladění síťových požadavků — pro vývojové sestavení by měl být pinning vypnut prostřednictvím příznaku BuildConfig.DEBUG a QA testování by mělo být prováděno na release podpisu se zapnutou ochranou. Některé týmy používají staging doménu s odděleným pinning certifikátem pro vývojové prostředí, aby zachovaly ochranu i ve fázi vývoje.

Implementace Certificate Pinning v Android

Podívejme se na příklad implementace Certificate Pinning na Android pomocí OkHttp — standardní knihovny pro síťové požadavky. OkHttp poskytuje vestavěný CertificatePinner, který přijímá SHA-256 hashe veřejných klíčů.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

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

V kódu výše přidáváme dva piny pro doménu api.example.com: hlavní (aktuální certifikát) a záložní (pro případ rotace). OkHttp automaticky kontroluje, zda certifikát serveru odpovídá jednomu z uvedených SHA-256 otisků. Pro získání SHA-256 otisku certifikátu se používá příkaz: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Je důležité ukládat otisky ne v otevřené podobě v kódu, ale šifrované nebo zatemňené: statická analýza MobSF snadno najde holé SHA-256 řetězce v DEX souborech. Doporučuje se ukládat piny v res/raw zdrojích, šifrované AES, a dešifrovat je při startu aplikace prostřednictvím nativního kódu (NDK/JNI).

Implementace na iOS pomocí TrustKit

Na iOS je hlavním nástrojem pro Certificate Pinning opensourcová knihovna TrustKit. Na rozdíl od OkHttp se TrustKit konfiguruje deklarativně prostřednictvím Info.plist, což umožňuje měnit piny bez překompilování aplikace. Konfigurace obsahuje slovník s doménami a pole SHA-256 otisků veřejných klíčů. TrustKit automaticky zachycuje NSURLSession požadavky a kontroluje certifikáty před zahájením přenosu dat. Klíčovou vlastností TrustKit je podpora zpráv o validaci pinů: knihovna může odesílat zprávy na zadaný endpoint při neshodě pinu, což umožňuje rychle reagovat na anomálie certifikátů. Apple také poskytuje nativní mechanismus NSPinnedDomains v Info.plist od iOS 14, ale TrustKit zůstává preferovanou volbou díky flexibilnější konfiguraci, podpoře hlášení a možnosti horké výměny pinů bez aktualizace systému. TrustKit se integruje s URLSession prostřednictvím delegáta didReceiveChallenge, vrací .performDefaultHandling při úspěšném ověření pinu a .cancelAuthenticationChallenge při neshodě. Pro monitorování zpráv o validaci pinů se doporučuje nakonfigurovat samostatný endpoint, který analyzuje četnost chyb: pokud počet zpráv náhle vzroste — může to znamenat útok MitM nebo blížící se vypršení certifikátu, vyžadující okamžitou aktualizaci pinů.