SSL Pinning: lényeg, mechanizmus és védelem a MITM-támadások ellen

Mi az SSL Pinning?

SSL Pinning — egy biztonsági mechanizmus, amely során a mobil vagy webes alkalmazás megjegyzi a szerver megbízható tanúsítványát vagy nyilvános kulcsát, és elutasít minden olyan kapcsolatot, amelynek tanúsítványa nem egyezik a mentettel. A szabványos HTTPS-sémában az ügyfél a megbízhatósági láncon keresztül ellenőrzi a tanúsítványt a gyökér CA-ig — bármely CA aláírhat tanúsítványt bármely domainhez. Az SSL Pinning kiküszöböli ezt a gyengeséget: ahelyett, hogy több száz CA-nak bízna, az alkalmazás csak egy adott tanúsítványnak bízik.

A szabványos ellenőrzés problémája az, hogy a több száz gyökér CA bármelyike kiadhat érvényes tanúsítványt az Ön domainjéhez — véletlenül vagy kényszer hatására. Az a támadó, aki hozzáférést szerez egy saját gyökértanúsítvánnyal rendelkező vállalati proxyhoz, MITM-támadást hajthat végre a böngésző figyelmeztetése nélkül. Az SSL Pinning bezárja ezt a sérülékenységet: még ha a CA hamis tanúsítványt is ad ki, az alkalmazás elutasítja, mert az ujjlenyomat nem egyezik a rögzítettel.

A mobilos alkalmazásokban az SSL Pinning különösen fontos, mert az eszközök gyakran nem biztonságos hálózatokon működnek — nyilvános Wi-Fi, forgalomellenőrző vállalati proxyk, fertőzött hozzáférési pontok. A Verizon Mobile Security Index (2025) szerint a mobilos alkalmazásokban bekövetkező adatszivárgások több mint 60%-a a forgalom szállítási rétegben történő elfogásával kapcsolatos.

Miért van szükség SSL Pinningre a mobilfejlesztésben

A mobilos alkalmazások érzékeny adatokat továbbítanak — hitelesítési tokeneket, fizetési információkat, felhasználók személyes adatait. További védelem nélkül a HTTPS kompromittálható a gyökértanúsítvány eszközön történő helyettesítésével — például vállalati profil vagy rosszindulatú alkalmazás telepítése után. Az SSL Pinning garantálja, hogy még ha hamis gyökér CA van is telepítve az eszközön, az alkalmazás továbbra is a saját fehérlistája alapján ellenőrzi a tanúsítványt.

Hogyan működik az SSL Pinning?

Az SSL Pinning folyamata három szakaszból áll: ujjlenyomat megszerzése, ellenőrzés a kapcsolódáskor és hibakezelés. A fejlesztési szakaszban a mérnök megszerzi a szerver tanúsítványának SHA-256 ujjlenyomatát (openssl x509 -fingerprint -sha256), és beágyazza az alkalmazás kódjába vagy konfigurációs fájljába. Minden HTTPS-kérésnél az alkalmazás kiszámítja a kapott tanúsítvány ujjlenyomatát, és összehasonlítja a mentettel — ha az értékek nem egyeznek, a kapcsolat megszakad.

Első szakasz — pinning a build fázisban: a fejlesztő előre ismeri a szerver tanúsítványait és beágyazza a hash-eket. Második szakasz — pinning az első kapcsolódáskor (trust on first use, TOFU): az alkalmazás az első kérésnél megjegyzi a tanúsítványt, és azt használja az összes további kérés ellenőrzéséhez. A TOFU kényelmes dinamikus környezetekhez, de sérülékeny az első támadásnál — ha az első kapcsolat már el van fogva, a hamis tanúsítvány megbízhatóként lesz elfogadva.

Kritikus részlet — biztonsági ujjlenyomatok (backup pins). A tanúsítványoknak lejárati idejük van, és cseréjükkor a nem frissített alkalmazás elveszti a kapcsolatot a szerverrel. A mérnökök 2–3 további ujjlenyomatot adnak hozzá — például a biztonsági tanúsítvány ujjlenyomatát és a gyökér CA ujjlenyomatát. Ha a fő tanúsítvány megváltozik, az alkalmazás a backup pins alapján ellenőriz, és a kapcsolat továbbra is működik.

# A tanúsítvány SHA-256 ujjlenyomatának megszerzése
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

Az SSL Pinning típusai

A pinning implementációjának két fő megközelítése van: a teljes tanúsítványhoz való rögzítés (certificate pinning) és a nyilvános kulcshoz való rögzítés (public key pinning). Mindkét megközelítésnek megvannak a maga erősségei és korlátai, amelyek befolyásolják a biztonságot és a karbantartás egyszerűségét.

Certificate Pinning

Tanúsítványhoz rögzítés — a legszigorúbb módszer. Az alkalmazás tárolja a megbízható tanúsítvány másolatát vagy annak SHA-256 ujjlenyomatát, és minden HTTPS-kapcsolatnál összehasonlítja a szerver tanúsítványával. Ez a módszer maximális biztonságot nyújt, de rotációnál problémákat okoz — a tanúsítványok általában 1–2 évig érvényesek, ezután az alkalmazás kényszerített frissítése szükséges. Kritikus rendszerekhez ajánlott, ellenőrzött frissítési ciklussal.

Public Key Pinning

A nyilvános kulcs rögzítése — egy rugalmasabb megközelítés. A teljes tanúsítvány helyett az alkalmazás csak a szerver RSA vagy ECDSA nyilvános kulcsát jegyzi meg. A kulcs változatlan maradhat a tanúsítvány újbóli kiadásakor, ha a vállalat ugyanazt a kulcspárt használja. Ez csökkenti az alkalmazásfrissítések gyakoriságát. Ha azonban a kulcs kompromittálódik, minden ügyfélnél lépcsőzetes cserére lesz szükség.

SSL Pinning iOS-en

Az Apple platformon az SSL Pinning az URLSession delegátuson keresztül implementálható. A fejlesztő létrehoz egy osztályt, amely implementálja az URLSessionDelegate protokollt, és felülírja a didReceive challenge metódust, ahol manuálisan ellenőrzi a szerver tanúsítványát a mentett ujjlenyomatokkal szemben. Alternatív megközelítés — az Alamofire használata ServerTrustManagerrel, amely egyszerűsíti a konfigurációt.

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

A példában a delegátus hitelesítési kérelmet kap az URLSession-től, kinyeri a serverTrust-ot a challenge-ből, és összehasonlítja a tanúsítvány SHA-256 ujjlenyomatát a mentettel. Ha az ujjlenyomat egyezik — a kapcsolat folytatódik, ellenkező esetben a challenge elutasításra kerül. Éles környezethez érdemes több backup pins ellenőrzését és hibanaplózást hozzáadni a monitorozáshoz.

Network Security Config iOS-en

Az iOS 14-től kezdve az Apple beépített támogatást adott a Certificate Pinninghez az Info.plisten keresztül. A fejlesztő megadja a megbízható tanúsítványokat a NSAppTransportSecurity kulcsban az NSPinnedDomains alkulcsszótárral. Ez a megközelítés nem igényel kódírást, de kevésbé rugalmas — a pinsek nem módosíthatók dinamikusan, és az ellenőrzési hibák sem naplózhatók.

SSL Pinning Androidon

Androidon három fő módja van az SSL Pinning implementálásának: az OkHttp könyvtár CertificatePinnerén keresztül, a Network Security Configon keresztül XML-ben és egyedi ellenőrzéssel a HttpsURLConnection-ben. Az OkHttp — a legnépszerűbb és ajánlott megközelítés, amelyet a Retrofit-ban és más HTTP-kliensekben használnak.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // biztonsági pin
    .build()

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

Az OkHttp konfigurációjában a fejlesztő megadja a domaint és egy vagy több SHA-256 ujjlenyomatot. Az első ujjlenyomatnál az OkHttp összehasonlítja a szerver tanúsítványát a megadott pinsekkel. Ha nincs egyezés, az ügyfél SSLPeerUnverifiedException kivételt dob. A biztonsági pin kötelező — nélküle a tanúsítvány váltásakor az API-kérések azonnal meghiúsulnak.

Network Security Configuration Androidon

Az Android API 24-től kezdve támogatja a deklaratív Certificate Pinninget XML-konfiguráción keresztül. A res/xml/network_security_config.xml fájl tartalmazza a domainek és ujjlenyomataik listáját. Ez a módszer kényelmes statikus konfigurációkhoz, de nem teszi lehetővé a TOFU vagy egyedi ellenőrzési logika implementálását naplózással.

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

Az SSL Pinning előnyei és hátrányai

Az SSL Pinning jelentősen növeli a mobilos alkalmazás biztonságát, de működési komplexitást hoz. A fő előny — védelem a MITM-támadások ellen még a gyökér CA-k kompromittálódása esetén is. Az alkalmazás csak azoknak a tanúsítványoknak bízik, amelyeket a fejlesztő kifejezetten megadott, nem a nyilvános tanúsítványközpontok teljes infrastruktúrájának. Ez különösen kritikus a pénzügyi alkalmazások, üzenetküldők és érzékeny adatokkal dolgozó alkalmazások esetében.

A fő hátrány — a tanúsítványrotáció bonyolultsága. Ha egy tanúsítvány lejár vagy visszavonásra kerül, a nem frissített alkalmazást használó felhasználók elveszítik a kapcsolatot. Ez backup pinsekkel és fokozatos frissítési mechanizmussal oldható meg: az új alkalmazás ismeri a régi és az új tanúsítványt, és a felhasználók teljes frissítése után a régi pin eltávolításra kerül a kódból. Javasolt minimum 2 backup pin elhelyezése — egy a jelenlegi tanúsítványhoz, egy a jövőbelihez.

Egy másik kompromisszum — a nyilvános proxyk használatának lehetetlensége a forgalom hibakereséséhez (Charles Proxy, Burp Suite) a pinning kikapcsolása nélkül. Ez megnehezíti a hálózati kérések hibakeresését a fejlesztési szakaszban. Megoldás — feltételes fordítás: a debug buildben a pinning ki van kapcsolva, a release buildben be van kapcsolva. Az OWASP a BuildConfig.DEBUG zászló használatát javasolja a váltáshoz.