Certificate Pinning: mi ez, tanúsítványrögzítési módszerek és hogyan valósítsuk meg

A Certificate Pinning előnyei és hátrányai

Certificate Pinning jelentősen növeli a mobilalkalmazás biztonságát, de működési terhet ró a fejlesztőcsapatra. Fontos mérlegelni a védelem előnyeit és a kapcsolat blokkolásának kockázatát helytelen megvalósítás esetén.

A fő előny — védelem a Man-in-the-Middle támadások ellen, beleértve a CA feltörésének eseteit. A pinning haszontalanná teszi a támadó által kiadott hamis tanúsítványokat: még ha a CA alá is írt egy hamisítványt, az alkalmazás elutasítja azt. További előny — védelem a forgalom ellenőrzéséhez tanúsítványokat lecserélő vállalati proxy szerverek ellen. A Google Security Blog (2023) szerint a pinninggel rendelkező alkalmazásoknak 86%-kal kisebb az esélyük a forgalom elfogásával történő feltörésre, mint a csak szabványos TLS-ellenőrzést használó alkalmazásoknak.

A pinning fő hátránya — az önblokkolás kockázata: ha a szerver tanúsítványa megváltozik (meghosszabbítás, szolgáltatóváltás, kulcsrotáció) az alkalmazás frissítésének megjelenése előtt, a felhasználók elveszítik a hozzáférést a szerverhez. További hátrányok: a hibakeresés nehézsége (minden beállításváltozásnál frissíteni kell a pineket), az APK méretének 5–15 KB-os növekedése a TrustKit használatakor, és a változtatások gyors visszavonásának lehetetlensége új verzió nélkül. A kockázatok minimalizálására tartalék pineket, 2–3 havonta automatikus rotációt, valamint türelmi időszakot (grace period) használnak, amelyben az alkalmazás elfogadja mind a régi, mind az új tanúsítványt. Azt is figyelembe kell venni, hogy bekapcsolt pinning mellett a fejlesztés során nem használhatók proxy eszközök (Burp Suite, Charles) a hálózati kérések hibakereséséhez — a fejlesztői build-eknél a pinninget ki kell kapcsolni a BuildConfig.DEBUG jelzővel, a QA tesztelést pedig a kiadási aláíráson kell elvégezni bekapcsolt védelemmel. Egyes csapatok külön pinning tanúsítvánnyal rendelkező staging domaint használnak a fejlesztői környezet számára, hogy megőrizzék a védelmet még a fejlesztési fázisban is.

A Certificate Pinning megvalósítása Androidon

Nézzünk egy példát a Certificate Pinning Androidon történő megvalósítására az OkHttp — a hálózati kérésekhez használt szabványos könyvtár — segítségével. Az OkHttp beépített CertificatePinnert biztosít, amely elfogadja a nyilvános kulcsok SHA-256 hash-eit.

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

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

A fenti kódban két pint adunk hozzá az api.example.com domainhez: elsődleges (aktuális tanúsítvány) és tartalék (rotáció esetére). Az OkHttp automatikusan ellenőrzi, hogy a szerver tanúsítványa megfelel-e a megadott SHA-256 ujjlenyomatok egyikének. A tanúsítvány SHA-256 ujjlenyomatának lekéréséhez a parancs használatos: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Fontos, hogy az ujjlenyomatokat ne nyílt formában tároljuk a kódban, hanem titkosítva vagy elhomályosítva: a MobSF statikus elemzése könnyen megtalálja a puszta SHA-256 karakterláncokat a DEX fájlokban. Ajánlott a pineket a res/raw erőforrásokban tárolni, AES-en keresztül titkosítva, és az alkalmazás indításakor natív kóddal (NDK/JNI) visszafejteni.

Megvalósítás iOS-en a TrustKit segítségével

iOSen a Certificate Pinning fő eszköze a nyílt forráskódú TrustKit könyvtár. Az OkHttp-val ellentétben a TrustKit deklaratív módon konfigurálható az Info.plisten keresztül, ami lehetővé teszi a pinek megváltoztatását az alkalmazás újrafordítása nélkül. A konfiguráció egy doméneket tartalmazó szótárat és a nyilvános kulcsok SHA-256 ujjlenyomatainak tömbjét foglalja magában. A TrustKit automatikusan elfogja az NSURLSession kéréseket, és ellenőrzi a tanúsítványokat az adatátvitel megkezdése előtt. A TrustKit egyik kulcsfontosságú jellemzője — a pin-érvényesítési jelentések támogatása: a könyvtár jelentéseket küldhet egy megadott végpontra pin eltérés esetén, ami gyors reagálást tesz lehetővé a tanúsítvány-anomáliákra. Az Apple natív NSPinnedDomains mechanizmust is biztosít az Info.plist-ben iOS 14-től kezdve, de a TrustKit továbbra is előnyösebb választás a rugalmasabb konfiguráció, a jelentéstámogatás és a pinek rendszerfrissítés nélküli cseréjének lehetősége miatt. A TrustKit a didReceiveChallenge delegate-en keresztül integrálódik az URLSession-nel, sikeres pin-ellenőrzéskor .performDefaultHandling, eltérés esetén .cancelAuthenticationChallenge értéket ad vissza. A pin-érvényesítési jelentések figyeléséhez ajánlott egy külön végpontot konfigurálni, amely elemzi a hibák gyakoriságát: ha a jelentések száma hirtelen megnő — ez MitM támadást vagy a tanúsítvány küszöbönálló lejáratát jelezheti, ami azonnali pin-frissítést igényel.