SSL Pinning: podstata, mechanismus a ochrana před MITM útoky

Co je SSL Pinning?

SSL Pinning — je bezpečnostní mechanismus, při kterém si mobilní nebo webová aplikace zapamatuje důvěryhodný certifikát nebo veřejný klíč serveru a odmítá jakákoli spojení, jejichž certifikát neodpovídá uloženému. Ve standardním schématu HTTPS klient ověřuje certifikát prostřednictvím řetězce důvěry až ke kořenové CA — jakákoli CA může podepsat certifikát pro jakoukoli doménu. SSL Pinning odstraňuje tuto slabinu: namísto důvěry stovkám CA aplikace důvěřuje pouze jednomu konkrétnímu certifikátu.

Problém standardního ověřování spočívá v tom, že kterákoli ze stovek kořenových CA může vydat platný certifikát pro vaši doménu — náhodně nebo pod nátlakem. Útočník, který získá přístup k firemní proxy s vlastním kořenovým certifikátem, může provést MITM útok bez varování prohlížeče. SSL Pinning uzavírá tuto zranitelnost: i když CA vydá podvržený certifikát, aplikace jej odmítne, protože otisk neodpovídá zaznamenanému.

V mobilních aplikacích je SSL Pinning obzvláště důležitý, protože zařízení často pracují v nezabezpečených sítích — veřejné Wi-Fi, firemní proxy s kontrolou provozu, infikované přístupové body. Podle Verizon Mobile Security Index (2025) více než 60% úniků dat v mobilních aplikacích souvisí se zachycením provozu na transportní vrstvě.

Proč je SSL Pinning potřeba v mobilním vývoji

Mobilní aplikace přenášejí citlivá data — autentizační tokeny, platební informace, osobní údaje uživatelů. Bez dodatečné ochrany může být HTTPS kompromitováno prostřednictvím náhrady kořenového certifikátu na zařízení — například po instalaci firemního profilu nebo škodlivé aplikace. SSL Pinning zaručuje, že i když je na zařízení nainstalována podvržená kořenová CA, aplikace bude nadále ověřovat certifikát podle vlastního bílého seznamu.

Jak funguje SSL Pinning?

Proces SSL Pinning sestává ze tří fází: získání otisku, ověření při připojení a zpracování chyby. Ve fázi vývoje inženýr získá SHA-256 otisk certifikátu serveru (openssl x509 -fingerprint -sha256) a vloží jej do kódu aplikace nebo konfiguračního souboru. Při každém požadavku HTTPS aplikace vypočítá otisk přijatého certifikátu a porovná jej s uloženým — pokud se hodnoty neshodují, spojení je přerušeno.

První fáze — pinning ve fázi sestavení: vývojář předem zná certifikáty serveru a vloží jejich hashe. Druhá fáze — pinning při prvním připojení (trust on first use, TOFU): aplikace si zapamatuje certifikát při prvním požadavku a použije jej k ověření všech následujících. TOFU je vhodný pro dynamická prostředí, ale je zranitelný při prvním útoku — pokud je první spojení již zachyceno, podvržený certifikát bude přijat jako důvěryhodný.

Kritický detail — záložní otisky (backup pins). Certifikáty mají dobu platnosti a při jejich výměně ztratí neaktualizovaná aplikace spojení se serverem. Inženýři přidávají 2–3 další otisky — například otisk záložního certifikátu a otisk kořenové CA. Pokud se hlavní certifikát změní, aplikace ověřuje podle backup pinů a spojení nadále funguje.

# Získání SHA-256 otisku certifikátu
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

Typy SSL Pinning

Existují dva hlavní přístupy k implementaci pinnigu: připojení k celému certifikátu (certificate pinning) a připojení k veřejnému klíči (public key pinning). Každý přístup má své silné stránky a omezení, které ovlivňují bezpečnost a snadnost údržby.

Certificate Pinning

Připojení k certifikátu — nejpřísnější metoda. Aplikace ukládá kopii důvěryhodného certifikátu nebo jeho SHA-256 otisk a porovnává jej s certifikátem serveru při každém připojení HTTPS. Tato metoda poskytuje maximální bezpečnost, ale vytváří problémy při rotaci — certifikáty obvykle platí 1–2 roky, poté je vyžadována vynucená aktualizace aplikace. Doporučuje se pro kritické systémy s řízeným cyklem aktualizací.

Public Key Pinning

Fixace veřejného klíče — flexibilnější přístup. Místo celého certifikátu si aplikace pamatuje pouze veřejný klíč RSA nebo ECDSA serveru. Klíč může zůstat nezměněn při opětovném vydání certifikátu, pokud společnost používá stejný pár klíčů. To snižuje frekvenci aktualizací aplikace. Pokud je však klíč kompromitován, bude vyžadována kaskádová výměna u všech klientů.

SSL Pinning na iOS

Na platformě Apple je SSL Pinning implementován prostřednictvím delegáta URLSession. Vývojář vytvoří třídu implementující protokol URLSessionDelegate a přepíše metodu didReceive challenge, kde ručně ověřuje certifikát serveru proti uloženým otiskům. Alternativní přístup — použití Alamofire se ServerTrustManager, který zjednodušuje konfiguraci.

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

V příkladu delegát obdrží požadavek na autentizaci od URLSession, extrahuje serverTrust z challenge a porovná SHA-256 otisk certifikátu s uloženým. Pokud se otisk shoduje — spojení pokračuje, jinak je challenge odmítnuto. Pro produkci je vhodné přidat ověření několika backup pinů a protokolování chyb pro monitorování.

Network Security Config na iOS

Od iOS 14 Apple přidal vestavěnou podporu pro Certificate Pinning prostřednictvím Info.plist. Vývojář uvádí důvěryhodné certifikáty v klíči NSAppTransportSecurity s podslovníkem NSPinnedDomains. Tento přístup nevyžaduje psaní kódu, ale je méně flexibilní — nelze dynamicky měnit piny ani protokolovat chyby ověření.

SSL Pinning na Androidu

Na Androidu existují tři hlavní způsoby implementace SSL Pinning: přes CertificatePinner knihovny OkHttp, přes Network Security Config v XML a přes vlastní ověření v HttpsURLConnection. OkHttp — nejoblíbenější a doporučený přístup, používaný v Retrofit a dalších HTTP klientech.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // záložní pin
    .build()

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

V konfiguraci OkHttp vývojář uvádí doménu a jeden nebo více SHA-256 otisků. Při prvním otisku OkHttp porovná certifikát serveru s uvedenými piny. Pokud není shoda, klient vyvolá SSLPeerUnverifiedException. Záložní pin je povinný — bez něj při změně certifikátu začnou API požadavky okamžitě selhávat.

Network Security Configuration na Androidu

Android podporuje deklarativní Certificate Pinning prostřednictvím konfigurace XML od API 24. Soubor res/xml/network_security_config.xml obsahuje seznam domén a jejich otisků. Tato metoda je vhodná pro statické konfigurace, ale neumožňuje implementaci TOFU nebo vlastní logiky ověření s protokolováním anomálií.

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

Výhody a nevýhody SSL Pinning

SSL Pinning výrazně zvyšuje bezpečnost mobilní aplikace, ale přináší provozní složitost. Hlavní výhoda — ochrana před MITM útoky i při kompromitaci kořenových CA. Aplikace důvěřuje pouze certifikátům, které jsou výslovně uvedeny vývojářem, nikoli celé infrastruktuře veřejných certifikačních autorit. To je zvláště kritické pro finanční aplikace, messengery a aplikace s citlivými údaji.

Hlavní nevýhoda — složitost rotace certifikátů. Pokud certifikát vyprší nebo je odvolán, uživatelé bez aktualizace aplikace ztratí spojení. Řeší se pomocí záložních pinů a mechanismu postupně aktualizace: nová aplikace zná starý i nový certifikát a po úplné aktualizaci uživatelů je starý pin z kódu odstraněn. Doporučuje se vložit minimálně 2 záložní piny — jeden pro aktuální certifikát, jeden pro budoucí.

Další kompromis — nemožnost používat veřejné proxy pro ladění provozu (Charles Proxy, Burp Suite) bez vypnutí pinnigu. To komplikuje ladění síťových požadavků ve fázi vývoje. Řešení — podmíněná kompilace: v debug sestavení je pinning vypnutý, v release je zapnutý. OWASP doporučuje používat příznak BuildConfig.DEBUG pro přepínání.