Eit eigendefinert VPN-sertifikat er ikkje eit ekstra krypteringslag

Å installere eit eigendefinert sertifikat på eit VPN-endepunkt kjennest som å leggje til vern, fordi sertifikat og kryptering dukkar opp saman overalt. I praksis endrar det to ting: kva identitet endepunktet viser, og kva utferdar motparten er viljug til å stole på. Ingen av dei pakkar inn dataa dine ein gong til. Viss det eigenlege behovet er ein andre verna kanal, treng du ein andre kanal med eigne endepunkt, ikkje endå eit sertifikat.

Tre atskilde oppgåver i eit TLS 1.3-handtrykk

RFC 8446 held desse tinga atskilde, og nettopp denne atskilnaden er heile svaret. Certificate-meldinga ber sertifikatkjeda til endepunktet. CertificateVerify provar at den tilhøyrande private nøkkelen er på plass og bind transkriptet til handtrykket. Record-laget vernar trafikken med dei forhandla trafikknøklane.

Byt sertifikatet, og dei to fyrste punkta endrar seg. Record-vernet køyrer ikkje to gonger, og det blir ikkje sterkare fordi utferdaren no er privat.

Kva ein privat CA eigenleg kjøper

Han kjøper eit kontrollert identitetssystem: du avgjer kven som får utferd, du avgjer kva utferdarar motpartar godtek, og du kan trekkje tilbake etter din eigen tidsplan. Det er verkeleg nyttig når du driv begge endane.

Han fører òg med seg plikter. Tillit må fordelast medvite, motpartskontrollen må stå på, og nokon må eige livssyklusen til legitimasjonen. Ein privat CA er ingen snare veg rundt nokon av desse tre.

Når ein andre kanal er det rette svaret

Tenk deg at ein applikasjon opnar verifisert HTTPS til sin eigen teneste medan pakkane òg går gjennom ein VPN. Det designet har to grenser med mogleg ulike endepunkt, og slik ser ein andre verna kanal ut.

Skilnaden tel ved gatewayen. Viss TLS-økta til applikasjonen blir avslutta ved VPN-gatewayen i staden for ved applikasjonen, er vernet du trudde du hadde bortanfor tunnelen, ikkje der. Skriv ned kven som avsluttar kvar kanal før du hevdar eigenskapen.

Spør kva installasjonen endrar

Ein førespurnad om å installere eit sertifikat kan tyde tre ulike ting. Det kan endre identiteten til klienten sjølv, eit applikasjonsspesifikt tillitsanker eller tillit på plattformnivå til alt på eininga. Desse er ikkje likeverdige, og berre den siste påverkar programvare som ikkje er knytt til saka.

Spør kva av dei tre som er meint, og deretter kva det skal oppnå. Viss svaret er meir kryptering, er framlegget retta mot feil mekanisme.

Skriv ned grensene

For kvar kanal, noter endepunkta, identiteten kvar side verifiserer, og kva operatøren i midten kan sjå. Noter deretter feilåtferda: kva som skjer når verifiseringa feilar, og kva som skjer når kanalen blir avvist.

To linjer på éi side avgjer vanlegvis ein diskusjon som ein sertifikatrotasjon ikkje kan avgjere.

Avgjer med tre spørsmål

Er problemet kven endepunktet gir seg ut for å vere, eller kva som skjer med dataa? Må vernet halde fram forbi VPN-gatewayen til ein bestemd applikasjon? Og kan du namngje dei to endepunkta som ville avslutte ein andre kanal?

Viss det fyrste spørsmålet er det rette, rett opp identitet og tillit. Viss det andre eller tredje er det, design den andre kanalen og lat sertifikatet bli der det høyrer heime.