TLS-fastgørelse og VPN-adgang besvarer forskellige spørgsmål

Sæt en privat mobilapp bag en VPN, og en rimelig person vil spørge, om den stadig har brug for certifikatfastgørelse. Spørgsmålet lyder som et valg mellem to ligeværdige kontroller, og det er i virkeligheden et spørgsmål om to forskellige porte. VPN’en afgør, om denne enhed overhovedet må bruge vejen; appen afgør, om den server, den nåede, er den, den forventede. Svar på begge hver for sig, og designet bliver enklere.

To porte, to spørgsmål

Netværksadgang handler om klienten: er denne enhed tilmeldt, er dens legitimationsoplysninger gyldige, og tillader politikken den at komme ind på denne vej? Apptillid handler om serveren: nåede forbindelsen en tjeneste med en identitet, som appen accepterer? Disse svar kommer fra forskellige systemer, svigter af forskellige årsager og rettes af forskellige teams. Et VPN-håndtryk kan lykkes, mens appen taler med et udløbet certifikat bag peer’en. En perfekt fastgjort app kan stadig være utilgængelig for alle, fordi enheden aldrig kom på netværket.

De to lægges sammen. At droppe den ene fjerner en kontrol; at tilføje den anden erstatter den ikke.

Hvad en fastgørelse faktisk begrænser

En fastgørelse indsnævrer det sæt serveridentiteter, som appen vil acceptere, normalt ved at navngive en offentlig nøgle eller en certifikathash i stedet for at stole på enhver kæde, et lager ville garantere for. Det er en begrænsning lagt oven på almindelig validering, ikke en erstatning for den. Almindelig validering svarer på, om en kæde overhovedet er troværdig; fastgørelsen svarer på, om det er den kæde, denne app forventer. En implementering, der springer det første skridt over, har ikke vundet sikkerhed, kun nyhed.

Det objekt, der fastgøres, varierer mellem platforme, så selve ordet fortæller dig meget lidt. At kopiere en hash fra et produkts tillidslager og behandle den som det samme i en mobilapp er en almindelig og stille fejl.

Fastgørelse på platformen er en konfiguration, ikke en politik

Android eksponerer fastgørelse gennem sin netværkssikkerhedskonfiguration, hvor et fastgørelsessæt indeholder fingeraftryk af en offentlig nøgle, og kæden skal indeholde mindst én af dem. Den fil gælder for hver app og kræver en bevidst build-ændring. iOS har ingen tilsvarende manifestmekanisme, så fastgørelse dér lever i appens egen kode til tillidsvurdering.

Da mekanismen er forskellig, skal kravet skrives for hver platform. En politik, der siger fastgør certifikatet uden at navngive platformen, er ikke implementerbar.

Rotation afgør, om fastgørelsen overlever

Den svære del er ikke den første udgivelse, det er certifikatfornyelsen bagefter. En restriktiv tillidspolitik afviser en legitim ny nøgle lige så fast som en angribers.

To mekanismer gør rotation overlevelig: en backup-fastgørelse, der allerede er betroet, før den er nødvendig, og en udløbsdato på fastgørelsessættet, så håndhævelsen bortfalder i stedet for at gøre appen ubrugelig. Begge er politiske beslutninger, og udløbet er især en bevidst sikkerhedsnedsættelse, ikke en uskyldig timer. Navngiv, hvem der styrer appens build, TLS-endepunktet og certifikatfornyelsen, og sæt dem i én ændringsproces. Hvis det er tre forskellige teams, vil fastgørelsen til sidst forårsage et nedbrud, som ingen havde planlagt.

En mistet enhed er et tredje problem

Tilbagekaldelse af en VPN-legitimation afslutter ikke nødvendigvis en appsession, og en serverfastgørelse gør slet ingenting ved en telefon i en andens hånd. Enhedslås, opbevaring af legitimationsoplysninger, sessionslevetid og ekstern tilbagekaldelse er separate beslutninger med separate ejere. At folde dem ind i fastgørelsesdiskussionen garanterer, at ingen af dem bliver designet.

Test fire relationer i stedet for den ene, du kan se: den tilsigtede server og handling, en konto der bør afvises, en serveridentitet der bør forkastes, og den planlagte rotation. En fungerende VPN øver kun den første. Skriv ned, hvad hver test beviste, for den næste person vil antage, at en grøn tunnel betyder, at alle fire bestod.