Merită să stivuiți două straturi VPN? Trei condiții de verificat

Înainte de a adăuga un al doilea strat de criptare la un VPN, răspundeți sincer la o întrebare: ce mai deține observatorul după ce ambele straturi și-au făcut treaba? Dacă răspunsul este textul cifrat interior, neschimbat, atunci imbricarea a cumpărat timp și nimic altceva. Ce urmează este o procedură de decizie, nu o recomandare. Aceeași diagramă este procesor irosit într-o implementare și răspunsul corect în alta, iar doar trei condiții despart cele două.

Notați ce păstrează observatorul

Înregistrați obiectul pe care un adversar îl poate stoca astăzi, apoi secvența de eliminări care ar expune în cele din urmă textul clar. Un tunel exterior produce text cifrat; când protecția lui se termină, ceea ce rămâne este textul cifrat al tunelului interior, încă sigilat. Îndepărtarea unui înveliș nu este decriptare. Acea propoziție descrie imbricarea și este valabilă doar cât timp cheia interioară supraviețuiește. În momentul în care cele două straturi partajează ceva, linia temporală se prăbușește într-un singur eveniment.

Deci artefactul util este o linie temporală, nu o diagramă de casete. Pentru fiecare strat, notați punctul final, proprietarul cheii, verificarea identității și anul în care se așteaptă ca presupunerea să eșueze.

O modalitate practică de a vă testa propria afirmație: presupuneți că observatorul înregistrează totul și nu renunță niciodată. Sub această presupunere, proiectarea mai protejează încărcătura utilă pe durata de viață necesară? Dacă răspunsul depinde de faptul că observatorul alege să nu stocheze trafic, proiectarea nu are răspuns.

Condiția unu: straturile se termină în locuri diferite?

Imbricarea merită când cele două straturi se termină în domenii de încredere diferite, de exemplu o poartă IPsec administrată de furnizor în fața unui tunel la nivel de aplicație care se termină în propria rețea. Atunci spargerea stratului exterior produce text cifrat pe care doar gazda dumneavoastră îl poate deschide, iar furnizorul nu vede niciodată text clar. Puneți ambele straturi pe aceeași poartă și acea proprietate dispare. Cine compromite cutia citește traficul dintre cele două operațiuni de decriptare, indiferent câte învelișuri arată diagrama.

Verificați asta cu starea instalată, nu cu proiectarea. În Linux, ip xfrm state listează fiecare asociere de securitate și punctele ei finale, ceea ce stabilește unde se oprește de fapt fiecare strat.

Condiția doi: materialul cheilor este într-adevăr independent?

Două straturi construite dintr-un singur certificat, o singură cheie prepartajată sau o singură bibliotecă de furnizor sunt un singur strat cu pași în plus. Atunci o singură acreditare compromisă le deschide pe ambele, iar o singură eroare de implementare le elimină pe ambele deodată. Independența trebuie să fie vizibilă în configurație, nu afirmată pe un diapozitiv.

Aici stabilirea hibridă a cheilor depășește stivuirea tunelurilor. IKEv2 poate transporta mai multe schimburi de chei într-o singură negociere, astfel încât un grup clasic și un KEM post-cuantic pot ambele alimenta aceleași chei de sesiune în loc să fie înfășurate unul în jurul celuilalt. Rezultatul este o singură asociere de securitate ale cărei chei depind de ambele secrete, iar atacatorul trebuie să le spargă pe amândouă. Aceasta este o construcție documentată cu o compoziție definită, ceea ce un stivuit făcut în casă din două produse VPN nu este. În strongSwan, swanctl --list-sas tipărește propunerea negociată pentru fiecare SA, și astfel confirmați ce a rulat de fapt, nu ce ați configurat.

Condiția trei: datele supraviețuiesc presupunerii exterioare?

Un strat care trebuie să reziste douăzeci de ani are nevoie de un argument de douăzeci de ani. Înregistrarea acum și decriptarea mai târziu este ieftină, și de aceea un strat exterior clasic nu poate fi tratat ca un înveliș temporar în jurul a ceva mai puternic.

Întrebați când devine fiecare cheie recuperabilă, nu dacă cifrul este spart astăzi. Un schimb static de chei fără secretul înainte eșuează retroactiv în ziua în care cade cheia privată. Acordul efemer de chei eșuează doar pentru sesiunile pe care un atacator le poate ataca cât timp sunt active, sau când algoritmul însuși slăbește. Această diferență decide dacă un strat interior mai ajută în 2040. Ea decide și dacă stratul exterior schimbă ceva, pentru că un strat exterior cu durata de viață a cheii mai slabă devine pur și simplu cel mai timpuriu punct de pe linia temporală.

Ce să construiți în schimb când răspunsul este nu

Dacă oricare dintre cele trei condiții eșuează, renunțați la imbricare și cheltuiți efortul pe stratul care poartă cu adevărat cerința de durată. Configurați un schimb hibrid de chei în protocolul pe care îl rulați deja, mențineți implementarea actuală și notați compoziția pe care vă bazați. A numi ML-KEM într-un document de proiectare nu este o proprietate de securitate, iar FIPS 203 definește mecanismul de încapsulare a cheilor, nu tunelul dumneavoastră.

Acolo unde un al doilea strat chiar își merită locul, descrieți-l ca apărare în adâncime și nu ca dovadă. Apoi verificați compoziția: care punct final deține care cheie, ce identitate verifică fiecare parte și ce poate citi un operator cu acces la consolă. O proiectare care trece de aceste trei întrebări merită procesorul suplimentar. Una care nu trece este doar o diagramă.

Înainte de fereastra de schimbare, capturați tabelul SA curent și propunerile negociate, iar după ea capturați-le din nou și comparați, pentru că singura dovadă care contează este ceea ce dispozitivele au acceptat efectiv.