TLS-pinning og VPN-tilgang svarar på ulike spørsmål

Set ein privat mobilapp bak ein VPN, og ein fornuftig person vil spørje om han framleis treng sertifikatpinning. Spørsmålet høyrest ut som eit val mellom to likeverdige kontrollar, og det er eigentleg eit spørsmål om to ulike portar. VPN-en avgjer om denne eininga i det heile får bruke vegen; appen avgjer om serveren han nådde er den han venta. Svar på begge kvar for seg, og designet blir enklare.

To portar, to spørsmål

Nettverkstilgang handlar om klienten: er denne eininga registrert, er legitimasjonen hennar gyldig, og tillèt policyen henne denne vegen? Apptillit handlar om serveren: nådde sambandet ein teneste med ein identitet appen godtar? Desse svara kjem frå ulike system, sviktar av ulike grunnar, og ulike team rettar dei. Eit VPN-handtrykk kan lukkast medan appen snakkar med eit utløpt sertifikat bak peeren. Ein perfekt pinna app kan likevel vere utilgjengeleg for alle, fordi eininga aldri kom på nettverket.

Dei to leggst saman. Å droppe den eine fjernar ein kontroll; å leggje til den andre erstattar han ikkje.

Kva ein pin faktisk avgrensar

Ein pin snevrar inn settet med serveridentitetar appen vil godta, vanlegvis ved å namngje ein offentleg nøkkel eller ein sertifikathash i staden for å stole på kvar kjede eit lager ville gå god for. Det er ei avgrensing lagd oppå vanleg validering, ikkje ei erstatning for henne. Vanleg validering svarar på om ei kjede er til å stole på i det heile; pinnen svarar på om det er kjeda denne appen ventar. Ein implementasjon som hoppar over første trinn har ikkje vunne tryggleik, berre nyheit.

Objektet som blir pinna varierer mellom plattformer, så ordet åleine seier deg svært lite. Å kopiere ein hash frå eitt produkts tillitslager og handsame han som det same i ein mobilapp er ein vanleg og stille feil.

Pinning på plattforma er ein konfigurasjon, ikkje ein policy

Android eksponerer pinning gjennom nettverkssikkerheitskonfigurasjonen sin, der eit pinnesett held digestar av ein offentleg nøkkel og kjeda må innehalde minst éin av dei. Den fila er per app og krev ei medviten build-endring. iOS har ingen tilsvarande manifestmekanisme, så pinninga der lever i appen sin eigen kode for tillitsvurdering.

Sidan mekanismen er ulik, må kravet skrivast per plattform. Ein policy som seier pinn sertifikatet utan å namngje plattforma er ikkje gjennomførbar.

Rotasjon avgjer om pinnen overlever

Den vanskelege delen er ikkje første utgiving, det er sertifikatfornyinga etterpå. Ein restriktiv tillitspolicy avviser ein legitim ny nøkkel like fast som ein åtakar sin.

To mekanismar gjer rotasjon overlevande: ein reservepin som allereie er betrodd før han trengst, og ein utløpsdato på pinnesettet slik at handhevinga fell bort i staden for å gjere appen ubrukeleg. Begge er policyavgjerder, og utløpet er særleg ein medviten reduksjon i tryggleik, ikkje ein uskuldig timer. Namngje kven som styrer bygginga av appen, TLS-endepunktet og sertifikatfornyinga, og set dei i éin endringsprosess. Om det er tre ulike team, vil pinninga til slutt føre til eit avbrot ingen hadde planlagt.

Ei mista eining er eit tredje problem

Å trekkje tilbake ein VPN-legitimasjon avsluttar ikkje nødvendigvis ein appsesjon, og ein serverpin gjer absolutt ingenting med ein telefon i nokon andre si hand. Einingslås, lagring av legitimasjon, sesjonslevetid og tilbakekalling på avstand er separate avgjerder med separate eigarar. Å brette dei inn i pinningdiskusjonen garanterer at ingen av dei blir designa.

Test fire relasjonar i staden for den ein du ser: den tiltenkte serveren og operasjonen, ein konto som bør avvisast, ein serveridentitet som bør forkastast, og den planlagde rotasjonen. Eit fungerande VPN øver berre på den første. Skriv ned kva kvar test beviste, for den neste personen vil anta at ein grøn tunnel betyr at alle fire bestod.