Certificate Pinning: cos'è, metodi di fissaggio dei certificati e come implementarlo

Vantaggi e svantaggi del Certificate Pinning

Certificate Pinning aumenta significativamente la sicurezza delle applicazioni mobili ma impone un onere operativo al team di sviluppo. È importante valutare i benefici di sicurezza rispetto ai rischi di blocco della connessione dovuti a un'implementazione errata.

Il vantaggio principale è la protezione contro gli attacchi Man-in-the-Middle, inclusi i casi di compromissione della CA. Il pinning rende inutili i certificati falsi emessi da un utente malintenzionato: anche se una CA ha firmato un falso, l'applicazione lo rifiuterà. Un ulteriore vantaggio è la protezione contro i server proxy aziendali che sostituiscono i certificati per l'ispezione del traffico. Secondo Google Security Blog (2023), le applicazioni con pinning hanno l'86% di probabilità in meno di essere compromesse attraverso l'intercettazione del traffico rispetto alle applicazioni che utilizzano solo la verifica TLS standard.

Lo svantaggio principale del pinning è il rischio di autobloccaggio: se il certificato del server cambia (rinnovo, cambio fornitore, rotazione delle chiavi) prima del rilascio dell'aggiornamento dell'applicazione, gli utenti perdono l'accesso al server. Svantaggi aggiuntivi: complessità di debug (ogni modifica alla configurazione richiede aggiornamenti dei pin), aumento delle dimensioni dell'APK di 5–15 KB quando si utilizza TrustKit e l'impossibilità di annullare rapidamente le modifiche senza una nuova versione. Per minimizzare i rischi, vengono utilizzati pin di backup, rotazione automatica ogni 2–3 mesi e un periodo di grazia durante il quale l'applicazione accetta sia il certificato vecchio che quello nuovo. È anche importante considerare che durante lo sviluppo con pinning abilitato, gli strumenti proxy (Burp Suite, Charles) non possono essere utilizzati per eseguire il debug delle richieste di rete — per le build di sviluppo, il pinning deve essere disabilitato tramite il flag BuildConfig.DEBUG, e i test QA devono essere eseguiti sulla firma di rilascio con la protezione abilitata. Alcuni team utilizzano un dominio di staging con un certificato di pinning separato per l'ambiente di sviluppo per mantenere la protezione anche durante lo sviluppo.

Implementazione del Certificate Pinning su Android

Diamo un'occhiata a un esempio di implementazione del Certificate Pinning su Android utilizzando OkHttp — la libreria standard per le richieste di rete. OkHttp fornisce un CertificatePinner integrato che accetta hash SHA-256 di chiavi pubbliche.

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

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

Nel codice sopra, aggiungiamo due pin per il dominio api.example.com: il principale (certificato corrente) e un pin di backup (per la rotazione). OkHttp verifica automaticamente che il certificato del server corrisponda a una delle impronte SHA-256 specificate. Per ottenere l'impronta SHA-256 del certificato, utilizzare il comando: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. È importante memorizzare le impronte non come testo in chiaro nel codice, ma crittografate o offuscate: l'analisi statica di MobSF trova facilmente stringhe SHA-256 grezze nei file DEX. Si consiglia di memorizzare i pin nelle risorse res/raw, crittografati tramite AES, e decrittografarli all'avvio dell'applicazione tramite codice nativo (NDK/JNI).

Implementazione su iOS tramite TrustKit

Su iOS, lo strumento principale per il Certificate Pinning è la libreria open-source TrustKit. A differenza di OkHttp, TrustKit viene configurato dichiarativamente tramite Info.plist, consentendo di modificare i pin senza ricompilare l'applicazione. La configurazione include un dizionario con i domini e un array di impronte SHA-256 di chiavi pubbliche. TrustKit intercetta automaticamente le richieste NSURLSession e verifica i certificati prima dell'inizio della trasmissione dei dati. Una caratteristica critica di TrustKit è il supporto per i rapporti di validazione dei pin: la libreria può inviare rapporti a un endpoint specificato quando si verifica una discrepanza di pin, consentendo una risposta rapida alle anomalie dei certificati. Apple fornisce anche un meccanismo nativo NSPinnedDomains in Info.plist a partire da iOS 14, ma TrustKit rimane la scelta preferita grazie alla configurazione più flessibile, al supporto dei rapporti e alla possibilità di scambiare i pin a caldo senza aggiornamenti del sistema operativo. È importante notare che TrustKit si integra con URLSession tramite il delegato didReceiveChallenge, restituendo .performDefaultHandling in caso di verifica del pin riuscita e .cancelAuthenticationChallenge in caso di discrepanza. Per monitorare i rapporti di validazione dei pin, si consiglia di configurare un endpoint separato che analizzi la frequenza degli errori: se il numero di rapporti aumenta bruscamente — ciò potrebbe indicare un attacco MitM o una scadenza imminente del certificato che richiede un aggiornamento immediato dei pin.