Certificate Pinning: ce este, metode de fixare a certificatelor și cum se implementează

Avantaje și dezavantaje ale Certificate Pinning

Certificate Pinning crește semnificativ securitatea aplicației mobile, dar impune o sarcină operațională asupra echipei de dezvoltare. Este important să căntăriți beneficiile protecției și riscul de blocare a conexiunii la o implementare incorectă.

Principalul avantaj — protecția împotriva atacurilor Man-in-the-Middle, inclusiv cazurile de compromitere a CA. Pinning face inutile certificatele false emise de atacator: chiar dacă CA a semnat un fals, aplicația îl va respinge. Un plus suplimentar — protecția împotriva serverelor proxy corporative care înlocuiesc certificatele pentru inspecția traficului. Conform Google Security Blog (2023), aplicațiile cu pinning au șanse cu 86% mai mici de a fi sparte prin interceptarea traficului comparativ cu aplicațiile care folosesc doar verificarea standard TLS.

Principalul dezavantaj al pinning — riscul de autoblocare: dacă certificatul serverului se schimbă (prelungire, schimbarea furnizorului, rotația cheilor) înainte de lansarea actualizării aplicației, utilizatorii pierd accesul la server. Dezavantaje suplimentare: dificultatea depanării (la fiecare modificare a setărilor trebuie actualizate pinurile), creșterea dimensiunii APK cu 5–15 KB la utilizarea TrustKit și imposibilitatea de a reveni rapid la modificări fără o nouă versiune. Pentru minimizarea riscurilor, se folosesc pinuri de rezervă, rotație automată la fiecare 2–3 luni și o perioadă de grație (grace period) în care aplicația acceptă atât certificatul vechi, cât și pe cel nou. De asemenea, trebuie avut în vedere că, cu pinning-ul activat în timpul dezvoltării, nu se pot folosi instrumente proxy (Burp Suite, Charles) pentru depanarea cererilor de rețea — pentru versiunile de dezvoltare, pinning trebuie dezactivat prin flag-ul BuildConfig.DEBUG, iar testarea QA trebuie efectuată pe semnătura de lansare cu protecția activată. Unele echipe folosesc un domeniu staging cu un certificat pinning separat pentru mediul de dezvoltare, pentru a păstra protecția chiar și în faza de dezvoltare.

Implementarea Certificate Pinning în Android

Să examinăm un exemplu de implementare a Certificate Pinning pe Android folosind OkHttp — biblioteca standard pentru cereri de rețea. OkHttp oferă un CertificatePinner încorporat care acceptă hash-uri SHA-256 ale cheilor publice.

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

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

În codul de mai sus adăugăm două pinuri pentru domeniul api.example.com: principal (certificatul curent) și de rezervă (în caz de rotație). OkHttp verifică automat dacă certificatul serverului corespunde unuia dintre hash-urile SHA-256 specificate. Pentru a obține hash-ul SHA-256 al certificatului se folosește comanda: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Este important să stocați hash-urile nu în formă deschisă în cod, ci criptate sau ofuscate: analiza statică MobSF găsește ușor șirurile SHA-256 goale în fișierele DEX. Se recomandă stocarea pinurilor în resursele res/raw, criptate prin AES, și decriptarea lor la pornirea aplicației prin cod nativ (NDK/JNI).

Implementarea pe iOS prin TrustKit

Pe iOS, instrumentul principal pentru Certificate Pinning este biblioteca open-source TrustKit. Spre deosebire de OkHttp, TrustKit se configurează declarativ prin Info.plist, ceea ce permite schimbarea pinurilor fără recompilarea aplicației. Configurația include un dicționar cu domenii și un array de hash-uri SHA-256 ale cheilor publice. TrustKit interceptează automat cererile NSURLSession și verifică certificatele înainte de începerea transferului de date. O caracteristică cheie a TrustKit — suportul pentru rapoarte de validare a pinurilor: biblioteca poate trimite rapoarte la un endpoint specificat la nepotrivirea pinului, permițând reacția rapidă la anomalii ale certificatelor. Apple oferă, de asemenea, mecanismul nativ NSPinnedDomains în Info.plist începând cu iOS 14, dar TrustKit rămâne alegerea preferată datorită configurației mai flexibile, suportului pentru rapoarte și posibilității de înlocuire la cald a pinurilor fără actualizarea sistemului. TrustKit se integrează cu URLSession prin delegatul didReceiveChallenge, returnând .performDefaultHandling la verificarea reușită a pinului și .cancelAuthenticationChallenge la nepotrivire. Pentru monitorizarea rapoartelor de validare a pinurilor, se recomandă configurarea unui endpoint separat care analizează frecvența erorilor: dacă numărul de rapoarte crește brusc — aceasta poate indica un atac MitM sau expirarea iminentă a certificatului, necesitând actualizarea imediată a pinurilor.