Certificate pinning nelle applicazioni mobile e desktop

Il TLS standard considera attendibile qualsiasi certificato firmato da una delle circa 150 CA radice preinstallate nel sistema operativo. Se una CA radice viene compromessa o costretta a emettere un certificato, un attaccante può ottenerne uno per qualsiasi dominio e intercettare il traffico TLS. Il certificate pinning limita la relazione di fiducia a uno specifico certificato o a una specifica chiave pubblica, indipendentemente dalla CA che lo ha firmato. Un'applicazione con pinning rifiuta le connessioni ai propri server a meno che il server non presenti esattamente il certificato o la chiave attesi. Questa protezione è particolarmente preziosa per le app mobili, nelle quali gli utenti non possono ispezionare il traffico di rete e le soluzioni MDM aziendali potrebbero installare CA radice dell'organizzazione.

Esistono tre livelli di granularità del pinning: (1) Pin del certificato completo: deve corrispondere il certificato esatto codificato in DER. È l'approccio più fragile, perché si interrompe a ogni rinnovo del certificato. (2) Pin della chiave pubblica: vengono confrontati solo i byte di SubjectPublicKeyInfo (SPKI). Il pin sopravvive al rinnovo del certificato se viene mantenuta la stessa coppia di chiavi. (3) Hash dello SPKI: viene memorizzato SHA-256(SPKI) anziché la chiave grezza. Questo è l'approccio di HTTP Public Key Pinning (HPKP) e di Android Network Security Config. Il pinning della chiave pubblica o dello SPKI è preferibile: sopravvive alla rotazione della CA e al rinnovo del certificato, rilevando comunque gli attacchi MITM che utilizzano una coppia di chiavi diversa.

Android (API 24+) offre un meccanismo dichiarativo di pinning tramite Network Security Config in formato XML. Il file res/xml/network_security_config.xml specifica i pin per dominio: pin-set con digest="SHA-256" e l'hash SPKI codificato in base64. L'applicazione fa riferimento a questo file in AndroidManifest.xml tramite android:networkSecurityConfig. Android applica i pin a tutte le connessioni HTTP effettuate tramite HttpsURLConnection standard e OkHttp (quando viene utilizzato il gestore di attendibilità della piattaforma). Il pin-set richiede almeno un pin di backup (una chiave diversa o un pin della CA) per evitare il blocco dell'applicazione se la chiave primaria viene compromessa. La scadenza del pin (attributo expiration) obbliga le app ad aggiornarsi prima che i pin diventino obsoleti.

Le app iOS implementano il pinning nei delegate di NSURLSession. Il metodo delegate URLSession(_:didReceive:completionHandler:) riceve l'oggetto di attendibilità del server. L'applicazione chiama SecTrustEvaluateWithError per convalidare la catena, quindi estrae il certificato leaf con SecTrustGetCertificateAtIndex(trust, 0), ne esporta i byte SPKI, calcola l'hash SHA-256 e lo confronta con il pin memorizzato. TrustKit (libreria open source) incapsula questo modello con un pinning basato sulla configurazione e supporta più pin, la corrispondenza dei sottodomini e la modalità report-only. App Transport Security (ATS) di Apple è separato dal pinning: ATS impone versioni minime di TLS, ma non applica il pinning delle chiavi.

HTTP Public Key Pinning (HPKP, RFC 7469) tentava di aggiungere il pinning ai browser web tramite gli header delle risposte HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Il browser avrebbe memorizzato il pin per la durata di max-age e rifiutato le connessioni alle chiavi non corrispondenti. Chrome ha deprecato HPKP nel 2017 e lo ha rimosso nel 2019 a causa di guasti catastrofici: una singola configurazione errata o la perdita della chiave poteva bloccare permanentemente gli utenti fuori da un sito web, senza alcun percorso di ripristino. HPKP è ormai di fatto inutilizzabile nei browser web; il pinning a livello applicativo nelle app mobili rimane praticabile perché gli aggiornamenti dell'app possono distribuire nuovi pin.

OkHttp (ampiamente utilizzato su Android) supporta il pinning tramite CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Il secondo pin è quello di backup. OkHttp verifica che almeno un pin corrisponda a un certificato qualsiasi nella catena del server: leaf, intermedio o radice. Ciò consente di applicare il pinning a una CA intermedia, sopravvivendo alla rotazione del certificato leaf, oppure alla CA radice, sopravvivendo alla rotazione della CA intermedia. OkHttp genera un'eccezione SSLPeerUnverifiedException con un messaggio utile che elenca gli hash SPKI effettivi del server, rendendo semplice estrarre i pin durante lo sviluppo.

Il pinning alza il livello di difficoltà dell'intercettazione del traffico, ma non è inviolabile. Tecniche comuni di elusione sui dispositivi mobili: (1) Hook Frida: iniettare JavaScript nel processo dell'app per intercettare il metodo di verifica del pin e restituire incondizionatamente true. (2) Strumenti SSLUnpinning: script Frida/Objection automatizzati che prendono di mira le librerie di pinning più comuni (TrustKit, OkHttp, SecTrust nativo). (3) ROM personalizzata: eseguire il root del dispositivo e modificare lo stack TLS. (4) Repackaging: decompilare l'APK, modificare la configurazione del pinning e ricreare il pacchetto con un nuovo certificato. (5) Patch della memoria: modificare il bytecode di verifica durante l'esecuzione. Contromisure: rilevamento di root/jailbreak, offuscamento del codice e controlli di integrità (SafetyNet/App Attest).

Il rischio operativo maggiore del certificate pinning è il blocco irreversibile: se la chiave di produzione viene persa oppure il certificato scade e il backup non è disponibile, gli utenti rimangono esclusi finché non viene distribuito un aggiornamento dell'app (da alcuni giorni a diverse settimane). Buone pratiche: (1) Applicare sempre il pinning ad almeno due chiavi: quella attuale e una chiave di backup pre-generata, conservata offline (in un HSM o in un ambiente isolato). (2) Impostare una data di scadenza del pin e distribuire gli aggiornamenti dell'app prima di tale scadenza. (3) Monitorare gli errori dei pin tramite la modalità report-only prima di applicare il pinning. (4) Mantenere una pipeline di aggiornamento d'emergenza dell'app (con revisione accelerata) per gli incidenti di rotazione dei pin. (5) Applicare il pinning al livello della CA intermedia, non al certificato leaf, per consentire la rotazione dei certificati leaf senza aggiornare l'app.

Le applicazioni desktop scritte con Electron, Qt o codice nativo possono implementare il pinning utilizzando le API del proprio stack TLS. Le app Electron utilizzano l'evento app.on("certificate-error") e session.setCertificateVerifyProc() per implementare una verifica personalizzata. Il codice di rete Qt utilizza QSslSocket con una callback di verifica personalizzata. Le applicazioni .NET utilizzano ServicePointManager.ServerCertificateValidationCallback. Le app native Windows utilizzano WinHTTP con l'ispezione manuale dei certificati. Le applicazioni desktop devono affrontare ulteriori difficoltà: l'intercettazione TLS a livello del sistema operativo tramite proxy aziendali è comune e gli utenti potrebbero aspettarsi che la funzionalità proxy continui a funzionare; è quindi necessaria una decisione di policy per stabilire se il pinning si applichi solo a endpoint specifici.

Il certificate pinning complica i test automatizzati e le pipeline CI/CD. I test di integrazione che effettuano chiamate HTTPS reali ai server di staging devono utilizzare certificati di test i cui hash SPKI siano inclusi nella configurazione di test. Approcci possibili: (1) Varianti di build: la build di debug o staging include i pin del server di staging, mentre la build di release include i pin di produzione. (2) Override di Network Security Config: Android consente una configurazione dei pin riservata al debug. (3) Mock server: intercettare le richieste a livello del client HTTP prima di TLS, evitando completamente il pinning. (4) CA autofirmata per la CI: emettere certificati di test da una CA CI la cui radice sia considerata attendibile solo nelle build di test. Non distribuire mai in produzione una build con il pinning disabilitato.

I pin dei certificati sono in genere hash di chiavi pubbliche RSA o EC. Quando inizierà la migrazione post-quantistica, i server passeranno a ML-DSA (CRYSTALS-Dilithium) o a chiavi ibride. Gli hash SPKI inclusi nei pin cambieranno, perché cambieranno il tipo e la codifica della chiave. Le app che applicano il pinning ai certificati leaf o alle chiavi pubbliche dovranno eseguire aggiornamenti coordinati: (1) Distribuire una nuova versione dell'app con l'hash SPKI post-quantistico come pin di backup prima della migrazione del server. (2) Completare la migrazione del server. (3) Distribuire un aggiornamento che rimuova il vecchio pin classico. La finestra di transizione richiede un coordinamento accurato. Le app che applicano il pinning alle CA intermedie o radice saranno meno interessate: cambierà solo la chiave della CA, non necessariamente secondo la stessa tempistica dei certificati leaf.

Perché è preferibile eseguire il pinning dell'hash di SubjectPublicKeyInfo (SPKI) invece di quello del certificato completo?

Il certificate pinning limita la fiducia TLS a uno specifico certificato o a una specifica chiave pubblica, proteggendo dalla compromissione delle CA e dagli attacchi MITM. Il pinning dell'hash SPKI (SHA-256 di SubjectPublicKeyInfo) è preferibile al pinning del certificato completo perché resiste meglio ai rinnovi. Android utilizza Network Security Config in formato XML; iOS utilizza il delegato di URLSession con le API SecTrust; OkHttp supporta CertificatePinner. È sempre opportuno includere un pin di backup per evitare di bloccare l'applicazione. HPKP (l'header HTTP per i browser) è deprecato. Il pinning può essere aggirato tramite hook di Frida e modifiche alla ROM. La migrazione a chiavi post-quantistiche richiede aggiornamenti coordinati dell'app per aggiornare gli hash SPKI.