Un certificat VPN propi no és una capa de xifratge addicional

Instal·lar un certificat propi en un extrem de VPN sembla afegir protecció, perquè els certificats i el xifratge apareixen junts a tot arreu. A la pràctica canvia dues coses: quina identitat presenta l'extrem i a quin emissor el seu par està disposat a confiar. Cap de les dues envolta les vostres dades per segona vegada. Si la necessitat real és un segon canal protegit, cal un segon canal amb els seus propis extrems, no un altre certificat.

Tres tasques separades en un handshake TLS 1.3

RFC 8446 manté aquestes coses separades, i aquesta separació és tota la resposta. El missatge Certificate porta la cadena de certificats de l’extrem. CertificateVerify demostra la possessió de la clau privada corresponent i lliga la transcripció de l’handshake. La capa de registre protegeix el trànsit amb les claus de trànsit negociades.

Canvieu el certificat i els dos primers elements canvien. La protecció de registre no s’executa dos cops i no es fa més forta pel fet que l’emissor ara sigui privat.

Què compra realment una CA privada

Compra un sistema d’identitat controlat: decidiu qui rep l’emissió, decidiu quins emissors accepten els pars i podeu revocar segons el vostre calendari. Això és realment útil quan gestioneu tots dos extrems.

També importa obligacions. La confiança s’ha de distribuir deliberadament, la verificació del par ha de romandre activa i el cicle de vida de les credencials ha de tenir un responsable. Una CA privada no és cap drecera al voltant de cap d’aquestes tres.

Quan un segon canal és la resposta correcta

Suposem que una aplicació obre HTTPS verificat cap al seu propi servei mentre els seus paquets també viatgen per una VPN. Aquest disseny té dues fronteres amb extrems possiblement diferents, i així és com es veu un segon canal protegit.

La distinció importa a la passarel·la. Si la sessió TLS de l’aplicació acaba a la passarel·la VPN en lloc de l’aplicació, la protecció que pensàveu que teníeu més enllà del túnel no hi és. Escriviu qui acaba cada canal abans de reclamar la propietat.

Pregunteu què canvia la instal·lació

Una petició per instal·lar un certificat pot significar tres coses diferents. Pot canviar la identitat del propi client, un ancoratge de confiança específic d’una aplicació o la confiança a tota la plataforma per a tot el dispositiu. No són equivalents, i només l’última afecta programari no relacionat.

Pregunteu quina de les tres és la pretesa i després què ha d’aconseguir. Si la resposta és més xifratge, la proposta apunta al mecanisme equivocat.

Escriviu les fronteres

Per a cada canal, anoteu els extrems, la identitat que verifica cada costat i què pot veure l’operador del mig. Després anoteu el comportament en cas de fallada: què passa quan la verificació falla i què passa quan el canal es rebutja.

Dues línies en una pàgina solen resoldre una discussió que una rotació de certificats no pot.

Decidiu amb tres preguntes

El problema és qui diu l’extrem que és, o què passa amb les dades? La protecció ha de continuar més enllà de la passarel·la VPN fins a una aplicació concreta? I podeu anomenar els dos extrems que acabarien un segon canal?

Si la primera pregunta és la real, arregleu la identitat i la confiança. Si ho és la segona o la tercera, dissenyeu el segon canal i deixeu el certificat on li toca.