Et brugerdefineret VPN-certifikat er ikke et ekstra krypteringslag

At installere et brugerdefineret certifikat på et VPN-endpoint føles som at tilføje beskyttelse, fordi certifikater og kryptering optræder sammen overalt. I praksis ændrer det to ting: hvilken identitet endpointet fremviser, og hvilken udsteder dets modpart er villig til at stole på. Ingen af dem pakker dine data ind en anden gang. Hvis det reelle behov er en anden beskyttet kanal, har du brug for en anden kanal med egne endpoints, ikke endnu et certifikat.

Tre adskilte opgaver i et TLS 1.3-håndtryk

RFC 8446 holder disse ting adskilt, og selve adskillelsen er hele svaret. Certificate-beskeden bærer endpointets certifikatkæde. CertificateVerify beviser besiddelsen af den matchende private nøgle og binder håndtrykkets transskript. Recordlaget beskytter trafikken med de forhandlede trafiknøgler.

Udskift certifikatet, og de to første punkter ændres. Recordbeskyttelsen kører ikke to gange, og den bliver ikke stærkere, fordi udstederen nu er privat.

Hvad en privat CA egentlig køber

Den køber et kontrolleret identitetssystem: du bestemmer, hvem der får udstedt, du bestemmer, hvilke udstedere modparter accepterer, og du kan tilbagekalde efter din egen tidsplan. Det er virkelig nyttigt, når du driver begge ender.

Den indfører også forpligtelser. Tillid skal fordeles bevidst, modpartsverifikation skal forblive slået til, og nogen skal eje legitimationsoplysningernes livscyklus. En privat CA er ikke en genvej uden om nogen af de tre.

Hvornår en anden kanal er det rigtige svar

Antag, at en applikation åbner verificeret HTTPS til sin egen tjeneste, mens dens pakker også rejser gennem en VPN. Det design har to grænser med muligvis forskellige endpoints, og det er, hvordan en anden beskyttet kanal ser ud.

Forskellen betyder noget ved gatewayen. Hvis applikationens TLS-session afsluttes ved VPN-gatewayen i stedet for ved applikationen, er den beskyttelse, du troede, du havde ud over tunnelen, ikke der. Skriv ned, hvem der afslutter hver kanal, før du hævder egenskaben.

Spørg, hvad installationen ændrer

En anmodning om at installere et certifikat kan betyde tre forskellige ting. Det kan ændre klientens egen identitet, et applikationsspecifikt tillidsanker eller tillid på platformsniveau til alt på enheden. De er ikke ens, og kun den sidste påvirker urelateret software.

Spørg, hvilken af de tre der er tilsigtet, og spørg derefter, hvad den skal opnå. Hvis svaret er mere kryptering, er forslaget rettet mod den forkerte mekanisme.

Skriv grænserne ned

For hver kanal skal du registrere endpoints, den identitet hver side verificerer, og hvad operatøren i midten kan se. Registrér derefter fejladfærden: hvad der sker, når verifikationen fejler, og hvad der sker, når kanalen afvises.

To linjer på én side afgør som regel en diskussion, som en certifikatrotation ikke kan afgøre.

Afgør med tre spørgsmål

Er problemet, hvem endpointet udgiver sig for at være, eller hvad der sker med dataene? Skal beskyttelsen fortsætte forbi VPN-gatewayen til en bestemt applikation? Og kan du navngive de to endpoints, der ville afslutte en anden kanal?

Hvis det første spørgsmål er det rigtige, skal du rette identitet og tillid. Hvis det andet eller tredje er det, skal du designe den anden kanal og lade certifikatet blive, hvor det hører til.