Un certificat VPN propriu nu este un strat suplimentar de criptare

Instalarea unui certificat propriu pe un endpoint VPN pare să adauge protecție, pentru că certificatele și criptarea apar peste tot împreună. În practică schimbă două lucruri: ce identitate prezintă endpointul și în ce emitent este dispus partenerul său să aibă încredere. Niciuna dintre ele nu vă învelește datele a doua oară. Dacă nevoia reală este un al doilea canal protejat, aveți nevoie de un al doilea canal cu propriile endpointuri, nu de încă un certificat.

Trei sarcini separate într-un handshake TLS 1.3

RFC 8446 ține aceste lucruri separate, iar separarea este tot răspunsul. Mesajul Certificate transportă lanțul de certificate al endpointului. CertificateVerify dovedește deținerea cheii private corespunzătoare și leagă transcrierea handshake-ului. Stratul de înregistrări protejează traficul cu cheile de trafic negociate.

Înlocuiți certificatul și primele două elemente se schimbă. Protecția înregistrărilor nu rulează de două ori și nu devine mai puternică pentru că emitentul este acum privat.

Ce cumpără de fapt o CA privată

Cumpără un sistem de identitate controlat: dumneavoastră decideți cui se emite, dumneavoastră decideți ce emitenți acceptă partenerii, și puteți revoca după propriul calendar. Este cu adevărat util când administrați ambele capete.

Dar aduce și obligații. Încrederea trebuie distribuită în mod deliberat, verificarea partenerului trebuie să rămână activă, iar ciclul de viață al acreditărilor trebuie să aibă un proprietar. O CA privată nu este o scurtătură pe lângă niciuna dintre acestea trei.

Când un al doilea canal este răspunsul corect

Să presupunem că o aplicație deschide HTTPS verificat către propriul serviciu, în timp ce pachetele ei trec și prin VPN. Acel design are două granițe cu endpointuri posibil diferite, și exact așa arată un al doilea canal protejat.

Distincția contează la gateway. Dacă sesiunea TLS a aplicației se termină la gateway-ul VPN și nu la aplicație, protecția pe care credeați că o aveți dincolo de tunel nu este acolo. Notați cine termină fiecare canal înainte de a revendica proprietatea.

Întrebați ce schimbă instalarea

O cerere de instalare a unui certificat poate însemna trei lucruri diferite. Poate schimba identitatea clientului însuși, o ancoră de încredere specifică aplicației sau încrederea la nivel de platformă pentru tot ce este pe dispozitiv. Nu sunt echivalente, și doar ultima afectează software necorelat.

Întrebați care dintre cele trei este vizată, apoi ce ar trebui să realizeze. Dacă răspunsul este mai multă criptare, propunerea vizează mecanismul greșit.

Notați granițele

Pentru fiecare canal, notați endpointurile, identitatea pe care o verifică fiecare parte și ce poate vedea operatorul din mijloc. Apoi notați comportamentul la eșec: ce se întâmplă când verificarea eșuează și ce se întâmplă când canalul este refuzat.

Două rânduri pe o pagină rezolvă de obicei o dispută pe care rotația certificatelor nu o poate rezolva.

Decideți cu trei întrebări

Problema este cine pretinde că este endpointul, sau ce se întâmplă cu datele? Protecția trebuie să continue dincolo de gateway-ul VPN până la o aplicație anume? Și puteți numi cele două endpointuri care ar termina un al doilea canal?

Dacă prima întrebare este cea reală, corectați identitatea și încrederea. Dacă este a doua sau a treia, proiectați al doilea canal și lăsați certificatul unde îi este locul.