Il pinning TLS e l’accesso VPN rispondono a domande diverse
Un pin limita a quale server l’app si fida; la politica VPN decide chi raggiunge la rete. Nessuno dei due copre l’autorizzazione o un dispositivo smarrito.
Metti un’app mobile privata dietro una VPN e una persona ragionevole chiederà se ha ancora bisogno del pinning dei certificati. La domanda sembra una scelta tra due controlli equivalenti, ed è in realtà una domanda su due porte diverse. La VPN decide se questo dispositivo può usare il percorso; l’app decide se il server raggiunto è quello atteso. Rispondi alle due domande separatamente e il progetto diventa più semplice.
Due porte, due domande
L’ammissione alla rete riguarda il client: questo dispositivo è registrato, la sua credenziale è valida e la politica gli consente questo percorso? La fiducia dell’app riguarda il server: la connessione ha raggiunto un servizio con un’identità che l’app accetta? Queste risposte vengono da sistemi diversi, falliscono per motivi diversi e sono corrette da team diversi. Una stretta di mano VPN può riuscire mentre l’app parla con un certificato scaduto dietro il peer. Un’app perfettamente pinnata può restare irraggiungibile per tutti, perché il dispositivo non è mai entrato nella rete.
I due si sommano. Togliere uno elimina un controllo; aggiungere l’altro non lo sostituisce.
Che cosa limita davvero un pin
Un pin restringe l’insieme delle identità di server che l’app accetterà, di solito nominando una chiave pubblica o un digest di certificato invece di fidarsi di ogni catena che uno store garantirebbe. È un vincolo sovrapposto alla validazione ordinaria, non un suo sostituto. La validazione ordinaria risponde se una catena è affidabile; il pin risponde se è la catena che questa app si aspetta. Un’implementazione che salta il primo passo non ha guadagnato sicurezza, solo novità.
L’oggetto fissato varia tra piattaforme, quindi la parola da sola dice molto poco. Copiare un digest dallo store di fiducia di un prodotto e trattarlo come la stessa cosa in un’app mobile è un errore comune e silenzioso.
Il pinning sulla piattaforma è una configurazione, non una politica
Android espone il pinning tramite la sua configurazione di sicurezza di rete, dove un set di pin contiene digest di una chiave pubblica e la catena deve contenerne almeno uno. Quel file è per app e richiede una modifica deliberata della build. iOS non ha un meccanismo di manifest equivalente, quindi lì il pinning vive nel codice di valutazione della fiducia dell’app stessa.
Poiché il meccanismo differisce, il requisito va scritto per piattaforma. Una politica che dice fissa il certificato senza nominare la piattaforma non è attuabile.
La rotazione decide se il pin sopravvive
La parte difficile non è la prima release, è il rinnovo del certificato che segue. Una politica di fiducia restrittiva rifiuta una nuova chiave legittima con la stessa fermezza di quella di un attaccante.
Due meccanismi rendono la rotazione sopportabile: un pin di riserva già fidato prima che serva, e una data di scadenza sul set di pin perché l’applicazione della politica decada invece di bloccare l’app. Entrambi sono decisioni di politica, e la scadenza in particolare è una riduzione deliberata della sicurezza, non un timer innocuo. Nominate chi controlla la build dell’app, l’endpoint TLS e il rinnovo del certificato, e metteteli in un unico processo di cambiamento. Se sono tre team diversi, il pin finirà per causare un’interruzione che nessuno aveva pianificato.
Un dispositivo smarrito è un terzo problema
Revocare una credenziale VPN non chiude necessariamente una sessione dell’app, e un pin del server non fa assolutamente nulla per un telefono in mano ad altri. Blocco del dispositivo, archiviazione delle credenziali, durata della sessione e revoca remota sono decisioni separate con proprietari separati. Piegare queste decisioni nella discussione sul pinning garantisce che nessuna di esse venga progettata.
Provate quattro relazioni invece di quella che vedete: il server e l’operazione previsti, un account che dovrebbe essere rifiutato, un’identità di server che dovrebbe essere scartata e la rotazione pianificata. Una VPN funzionante esercita solo la prima. Annotate che cosa ha dimostrato ogni test, perché la persona successiva assumerà che un tunnel verde significhi che tutte e quattro sono passate.