Een eigen VPN-certificaat is geen extra versleutelingslaag

Een eigen certificaat op een VPN-eindpunt installeren voelt als extra bescherming, omdat certificaten en versleuteling overal samen opduiken. In de praktijk verandert het twee dingen: welke identiteit het eindpunt toont, en welke uitgever zijn tegenpartij bereid is te vertrouwen. Geen van beide wikkelt uw gegevens een tweede keer in. Als de echte behoefte een tweede beschermd kanaal is, hebt u een tweede kanaal met eigen eindpunten nodig, niet nog een certificaat.

Drie aparte taken in een TLS 1.3-handshake

RFC 8446 houdt deze zaken gescheiden, en juist die scheiding is het hele antwoord. Het Certificate-bericht draagt de certificaatketen van het eindpunt. CertificateVerify bewijst het bezit van de bijbehorende privésleutel en bindt het handshake-transcript. De recordlaag beschermt het verkeer met de onderhandelde verkeerssleutels.

Vervang het certificaat en de eerste twee punten veranderen. De recordbescherming loopt niet twee keer en wordt niet sterker omdat de uitgever nu particulier is.

Wat een particuliere CA werkelijk koopt

Zij koopt een beheerst identiteitssysteem: u bepaalt wie wordt uitgegeven, u bepaalt welke uitgevers tegenpartijen accepteren, en u kunt volgens uw eigen schema intrekken. Dat is echt nuttig wanneer u beide uiteinden beheert.

Zij brengt ook verplichtingen mee. Vertrouwen moet bewust worden verdeeld, verificatie van de tegenpartij moet aan blijven, en iemand moet eigenaar zijn van de levenscyclus van de inloggegevens. Een particuliere CA is geen sluipweg langs een van die drie.

Wanneer een tweede kanaal het juiste antwoord is

Stel dat een applicatie geverifieerde HTTPS opent naar haar eigen dienst terwijl haar pakketten ook door een VPN gaan. Dat ontwerp heeft twee grenzen met mogelijk verschillende eindpunten, en zo ziet een tweede beschermd kanaal eruit.

Het verschil doet ertoe bij de gateway. Als de TLS-sessie van de applicatie eindigt bij de VPN-gateway in plaats van bij de applicatie, is de bescherming die u dacht te hebben voorbij de tunnel er niet. Schrijf op wie elk kanaal beëindigt voordat u de eigenschap opeist.

Vraag wat de installatie verandert

Een verzoek om een certificaat te installeren kan drie verschillende dingen betekenen. Het kan de eigen identiteit van de client veranderen, een applicatiespecifiek vertrouwensanker, of platformbreed vertrouwen voor alles op het apparaat. Die zijn niet gelijkwaardig, en alleen de laatste beïnvloedt niet-gerelateerde software.

Vraag welke van de drie is bedoeld, en dan wat het moet bereiken. Als het antwoord meer versleuteling is, is het voorstel op het verkeerde mechanisme gericht.

Schrijf de grenzen op

Noteer voor elk kanaal de eindpunten, de identiteit die elke kant verifieert, en wat de operator in het midden kan zien. Noteer daarna het faalgedrag: wat er gebeurt als verificatie mislukt, en wat er gebeurt als het kanaal wordt geweigerd.

Twee regels op één pagina beslechten meestal een discussie die een certificaatrotatie niet kan beslechten.

Beslis met drie vragen

Is het probleem wie het eindpunt beweert te zijn, of wat er met de gegevens gebeurt? Moet bescherming doorlopen voorbij de VPN-gateway naar een specifieke applicatie? En kunt u de twee eindpunten noemen die een tweede kanaal zouden beëindigen?

Als de eerste vraag de juiste is, herstel identiteit en vertrouwen. Als het de tweede of derde is, ontwerp dan het tweede kanaal en laat het certificaat waar het hoort.