Certificate Pinning: mi ez, mechanizmus és rögzítési módszerek

Mi az a Certificate Pinning?

Certificate Pinning — egy biztonsági technika, ahol az alkalmazás tárolja egy megbízható tanúsítvány lenyomatát (fingerprint), és azt használja a HTTPS-kapcsolat létrehozásának egyetlen kritériumaként. A szabványos TLS-modellben a kliens ellenőrzi, hogy a szerver tanúsítványát egy megbízható root CA írta-e alá — a rendszerben előre telepített százok egyike. A Certificate Pinning ezt a láncot közvetlen ellenőrzéssel váltja fel: a tanúsítványnak meg kell egyeznie a tárolt mintával, vagy tartalmaznia kell a várt nyilvános kulcsot.

A szabványos modell problémája a CA-k kompromittálásának incidensei után vált nyilvánvalóvá — DigiNotar (2011), Comodo (2011), TrustCor (2022). Ha egy CA hamis tanúsítványt ad ki az Ön domainjéhez, a böngésző vagy alkalmazás érvényesként fogadja el. Certificate Pinning megakadályozza ezt a támadást: még egy tökéletesen aláírt hamis tanúsítvány is elutasításra kerül, mert a lenyomata nem egyezik az alkalmazásban rögzítettel.

A pinning kifejezés a pin — „csapszeg” vagy „rögzítő” szóból származik: a fejlesztő rögzíti a megbízható tanúsítványt, és bármilyen eltérés tőle blokkolja a kapcsolatot. A Mitre CWE-295 kutatása szerint a helytelen tanúsítvány-ellenőrzés továbbra is a top-10 legveszélyesebb biztonsági hiba közé tartozik a mobilos alkalmazásokban, és a Certificate Pinning ennek megelőzésének közvetlen módszere.

A Certificate Pinning története és fejlődése

Kezdetben a Certificate Pinning-et böngészőkben használták a HPKP (HTTP Public Key Pinning) mechanizmuson keresztül, amely az RFC 7469-ben lett szabványosítva. A fejlesztő elküldte a Public-Key-Pins HTTP-fejléect a várt kulcsok hash-eivel, és a böngésző megjegyezte azokat egy meghatározott időszakra. A HPKP azonban veszélyesnek bizonyult: egyetlen konfigurációs hiba hónapokra blokkolhatta a weboldalt. 2018-ban a Chrome megszüntette a HPKP támogatását, és most a szabvány szoftveres megvalósítás az kliens oldalon — a mobilalkalmazáson vagy böngészőkiegészítőn belül.

Hogyan működik a Certificate Pinning?

A Certificate Pinning folyamata három kulcsfontosságú szakaszból áll: a lenyomat kiszámítása, ellenőrzés a kapcsolódáskor és a hiba kezelése. Az előkészítési szakaszban a fejlesztő megszerzi az éles szerver tanúsítványának vagy nyilvános kulcsának SHA-256 hash-ét. A GDPR és PCI DSS szabványoknak megfelelő alkalmazásokhoz a láncban lévő köztes CA-k lenyomatainak rögzítése is szükséges.

Minden HTTPS-kérésnél az alkalmazás elfogja a TLS-hitelesítési visszahívást, kinyeri a szerver tanúsítványát és kiszámítja annak SHA-256 hash-ét. Ezt a hash-t összehasonlítja a tárolt megbízható lenyomatok listájával. Ha egyezést talál — a kapcsolat folytatódik. Ha nem — az alkalmazásnak meg kell szakítania a kapcsolatot és jelentenie kell a hibát, anélkül, hogy felfedné a megvalósítási részleteket a támadó előtt.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

A függvény egy X509Certificate objektumot kap a szervertől és a várt hash-t. Először kinyeri a tanúsítvány nyilvános kulcsát, kiszámítja az SHA-256 hash-t és Base64-be kódolja. Az eredményt összehasonlítja a várt lenyomattal. Éles környezetben érdemes 2–3 lenyomatból álló tömbön végzett ellenőrzést hozzáadni a rotáció támogatásához.

Certificate Pinning vs Public Key Pinning

A pinning megvalósításakor ki kell választani, hogy melyik kriptográfiai objektumot rögzítjük. A Certificate Pinning magához az X.509 tanúsítványhoz kapcsolódik — annak sorozatszámához, érvényességi időszakához és teljes láncához. A Public Key Pinning csak a tanúsítványon belüli nyilvános kulcsot rögzíti, figyelmen kívül hagyva a többi mezőt. A választás jelentősen befolyásolja a működési költségeket.

Public Key Pinning — az előnyben részesített választás a legtöbb projekthez. A szerverek nyilvános kulcsai általában változatlanok maradnak a tanúsítvány újjakiadásakor — a cég egyszerűen aláírja a régi kulcsot egy új tanúsítvánnyal. Ez azt jelenti, hogy az alkalmazásnak nem kell frissülnie a tanúsítvány változása után, ha a kulcspár nem változott. A Certificate Pinning azokhoz a forgatókönyvekhez ajánlott, ahol a fejlesztő teljes mértékben irányítja mind a szervert, mind a klienskódot, például vállalati alkalmazásokban szigorú frissítési ciklussal.

Trust On First Use (TOFU)

TOFU — stratégia, ahol a Certificate Pinning nincs előre konfigurálva, hanem megjegyzi a tanúsítványt az első kapcsolódáskor a szerverhez. Ez a megközelítés kényelmes azoknak az alkalmazásoknak, amelyek előre nem tudják, melyik szerverhez fognak kapcsolódni. Hátránya — sebezhetőség az első támadással szemben: ha az első kapcsolatot elfogják, a hamis tanúsítvány megbízhatóként kerül elfogadásra. A TOFU-t SSH-kapcsolatokban és néhány P2P protokollban használják.

Megvalósítás iOS-en és Androidon

Mindkét platformon a Certificate Pinning a TLS-kapcsolat elfogásával valósul meg a hálózati verem szintjén. iOS-en az URLSession delegáltat vagy Alamofire ServerTrustManager-t használnak. Androidon az előnyben részesített módszer az OkHttp CertificatePinner, amely be van építve a népszerű HTTP-kliensekbe és támogatja több lenyomat konfigurálását minden domainhez.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

A Swift függvényben a serverTrust-ból kinyerésre kerül a tanúsítványok lánca, mindegyikhez kiszámításra kerül az SHA-256 hash, és az eredmény összehasonlításra kerül a várttal. A lánc összes tanúsítványán való áthaladás lehetővé teszi a pinning megvalósítását a köztes CA szintjén — ha a köztes tanúsítvány egyezik, a kapcsolat elfogadásra kerül. Ez rugalmasságot biztosít a levéltanúsítványok rotációjában.

TrustManager Androidhoz (egyéni)

Ha az alkalmazás nem használ OkHttp-t, a Certificate Pinning egyéni X509TrustManager segítségével valósítható meg. Ez a módszer több kódot igényel, de teljes ellenőrzést biztosít az ellenőrzési folyamat felett. A TrustManager felülírja a checkServerTrusted metódust, ahol a fejlesztő kézzel ellenőrzi a szerver tanúsítványait és dönt a megbízhatóságról. Csak speciális forgatókönyvekhez ajánlott, ahol az OkHttp könyvtár nem érhető el.

Hibák a Certificate Pinning bevezetésénél

A leggyakoribb hiba — a tartalék pin-ek hiánya. A fejlesztő egyetlen tanúsítvány-lenyomatot helyez el, és annak lejáratakor a felhasználók tömegesen veszítik el a kapcsolatot. A minimálisan elfogadható konfiguráció — két lenyomat: jelenlegi tanúsítvány és tartalék. Optimális — három: jelenlegi, tartalék és a root CA lenyomata fallbackként.

A második hiba — a pin-ek nyílt formában történő tárolása a kódban. Az APK-hoz vagy IPA-hoz hozzáférő támadó könnyen kinyerheti és lecserélheti a lenyomatokat. A hash-ek obfuszkálása ajánlott: a sztring részekre bontása, tárolás titkosított erőforrásokban vagy számítás futási időben. Androidhoz a sztringkonstansok obfuszkálásával ellátott ProGuard hatékony.

A harmadik hiba — pinning fejlesztési tanúsítvány szintjén. A fejlesztési és éles tanúsítványok általában különböznek, de a fejlesztők gyakran elfelejtik átállítani a pin-eket a release-build elkészítésekor. Eredmény — az éles alkalmazás nem tud csatlakozni a szerverhez. Megoldás — külön pin-konfiguráció a debug és release számára a BuildConfig vagy flavour-specifikus erőforrások segítségével.

• Ignoring certificate chain — csak a levéltanúsítvány ellenőrzése a köztes CA-k figyelembevétele nélkül, ami megszakítja a kapcsolatot rotációnál
• Hardcoded dates — keménykódolt tanúsítvány lejárati dátumok, amelyek nem változnak a frissítés után
• No monitoring — riasztások hiánya a Certificate Pinning hibákhoz, ami miatt a problémák csak a felhasználóktól derülnek ki
• TOFU ellenőrzés nélkül — a Trust On First Use használata további ellenőrzés nélkül, ami lehetővé teszi az első MITM támadásnak a hamis tanúsítvány rögzítését