TLS-pinning og VPN-tilgang svarer på forskjellige spørsmål

Sett en privat mobilapp bak en VPN, og en fornuftig person vil spørre om den fortsatt trenger sertifikatpinning. Spørsmålet høres ut som et valg mellom to likeverdige kontroller, og det er egentlig et spørsmål om to forskjellige porter. VPN-en avgjør om denne enheten i det hele tatt får bruke veien; appen avgjør om serveren den nådde er den den forventet. Svar på begge hver for seg, og designet blir enklere.

To porter, to spørsmål

Nettverkstilgang handler om klienten: er denne enheten registrert, er legitimasjonen dens gyldig, og tillater policyen den denne veien? Apptillit handler om serveren: nådde forbindelsen en tjeneste med en identitet appen godtar? Disse svarene kommer fra forskjellige systemer, svikter av forskjellige grunner, og forskjellige team retter dem. En VPN-håndtrykk kan lykkes mens appen snakker med et utløpt sertifikat bak peeren. En perfekt pinnet app kan likevel være utilgjengelig for alle, fordi enheten aldri kom på nettverket.

De to legges sammen. Å droppe den ene fjerner en kontroll; å legge til den andre erstatter den ikke.

Hva en pin faktisk begrenser

En pin snevrer inn settet med serveridentiteter appen vil godta, vanligvis ved å navngi en offentlig nøkkel eller en sertifikathash i stedet for å stole på hver kjede et lager ville gå god for. Det er en begrensning lagt oppå vanlig validering, ikke en erstatning for den. Vanlig validering svarer på om en kjede er til å stole på i det hele tatt; pinnen svarer på om det er kjeden denne appen forventer. En implementasjon som hopper over første trinn har ikke vunnet sikkerhet, bare nyhet.

Objektet som pinnes varierer mellom plattformer, så ordet alene sier deg svært lite. Å kopiere en hash fra ett produkts tillitslager og behandle den som det samme i en mobilapp er en vanlig og stille feil.

Pinning på plattformen er en konfigurasjon, ikke en policy

Android eksponerer pinning gjennom sin nettverkssikkerhetskonfigurasjon, der et pinnesett holder digester av en offentlig nøkkel og kjeden må inneholde minst én av dem. Den filen er per app og krever en bevisst build-endring. iOS har ingen tilsvarende manifestmekanisme, så pinningen der lever i appens egen kode for tillitsvurdering.

Siden mekanismen er forskjellig, må kravet skrives per plattform. En policy som sier pinn sertifikatet uten å navngi plattformen er ikke gjennomførbar.

Rotasjon avgjør om pinnen overlever

Den vanskelige delen er ikke første utgivelse, det er sertifikatfornyelsen etterpå. En restriktiv tillitspolicy avviser en legitim ny nøkkel like fast som en angripers.

To mekanismer gjør rotasjon overlevelig: en reservepin som allerede er betrodd før den trengs, og en utløpsdato på pinnesettet slik at håndhevelsen faller bort i stedet for å gjøre appen ubrukelig. Begge er policybeslutninger, og utløpet er særlig en bevisst sikkerhetsreduksjon, ikke en uskyldig timer. Navngi hvem som styrer appens build, TLS-endepunktet og sertifikatfornyelsen, og sett dem i én endringsprosess. Hvis det er tre forskjellige team, vil pinningen til slutt forårsake et avbrudd ingen hadde planlagt.

En mistet enhet er et tredje problem

Å tilbakekalle en VPN-legitimasjon avslutter ikke nødvendigvis en appsesjon, og en serverpin gjør absolutt ingenting med en telefon i noen andres hånd. Enhetslås, lagring av legitimasjon, sesjonslevetid og ekstern tilbakekalling er separate beslutninger med separate eiere. Å brette dem inn i pinningdiskusjonen garanterer at ingen av dem blir designet.

Test fire relasjoner i stedet for den ene du ser: den tiltenkte serveren og operasjonen, en konto som bør avvises, en serveridentitet som bør forkastes, og den planlagte rotasjonen. En fungerende VPN øver bare på den første. Skriv ned hva hver test beviste, for den neste personen vil anta at en grønn tunnel betyr at alle fire besto.