Et egendefinert VPN-sertifikat er ikke et ekstra krypteringslag

Å installere et egendefinert sertifikat på et VPN-endepunkt føles som å legge til beskyttelse, fordi sertifikater og kryptering dukker opp sammen overalt. I praksis endrer det to ting: hvilken identitet endepunktet viser, og hvilken utsteder motparten er villig til å stole på. Ingen av dem pakker inn dataene dine en gang til. Hvis det egentlige behovet er en andre beskyttet kanal, trenger du en andre kanal med egne endepunkter, ikke nok et sertifikat.

Tre atskilte oppgaver i et TLS 1.3-håndtrykk

RFC 8446 holder disse tingene atskilt, og nettopp denne atskillelsen er hele svaret. Certificate-meldingen bærer endepunktets sertifikatkjede. CertificateVerify beviser besittelse av den tilhørende private nøkkelen og binder håndtrykkets transkript. Record-laget beskytter trafikken med de forhandlede trafikknøklene.

Bytt sertifikatet, og de to første punktene endres. Record-beskyttelsen kjører ikke to ganger, og den blir ikke sterkere fordi utstederen nå er privat.

Hva en privat CA egentlig kjøper

Den kjøper et kontrollert identitetssystem: du bestemmer hvem som får utstedt, du bestemmer hvilke utstedere motparter godtar, og du kan tilbakekalle etter din egen tidsplan. Det er virkelig nyttig når du driver begge endene.

Den fører også med seg forpliktelser. Tillit må fordeles bevisst, motpartsverifiseringen må stå på, og noen må eie livssyklusen til legitimasjonen. En privat CA er ingen snarvei rundt noen av disse tre.

Når en andre kanal er det riktige svaret

Anta at en applikasjon åpner verifisert HTTPS til sin egen tjeneste mens pakkene også går gjennom en VPN. Det designet har to grenser med mulig ulike endepunkter, og det er slik en andre beskyttet kanal ser ut.

Forskjellen betyr noe ved gatewayen. Hvis applikasjonens TLS-økt avsluttes ved VPN-gatewayen i stedet for ved applikasjonen, er beskyttelsen du trodde du hadde bortenfor tunnelen, ikke der. Skriv ned hvem som avslutter hver kanal før du hevder egenskapen.

Spør hva installasjonen endrer

En forespørsel om å installere et sertifikat kan bety tre forskjellige ting. Den kan endre klientens egen identitet, et applikasjonsspesifikt tillitsanker eller tillit på plattformnivå til alt på enheten. Dette er ikke likeverdig, og bare den siste påvirker ikke-tilknyttet programvare.

Spør hvilken av de tre som er ment, og deretter hva den skal oppnå. Hvis svaret er mer kryptering, er forslaget rettet mot feil mekanisme.

Skriv ned grensene

For hver kanal, noter endepunktene, identiteten hver side verifiserer, og hva operatøren i midten kan se. Noter deretter feiloppførselen: hva som skjer når verifiseringen feiler, og hva som skjer når kanalen avvises.

To linjer på én side avgjør vanligvis en diskusjon som en sertifikatrotasjon ikke kan avgjøre.

Avgjør med tre spørsmål

Er problemet hvem endepunktet utgir seg for å være, eller hva som skjer med dataene? Må beskyttelsen fortsette forbi VPN-gatewayen til en bestemt applikasjon? Og kan du navngi de to endepunktene som ville avslutte en andre kanal?

Hvis det første spørsmålet er det riktige, rett opp identitet og tillit. Hvis det andre eller tredje er det, design den andre kanalen og la sertifikatet bli der det hører hjemme.