Treba li slagati dva VPN sloja? Tri uslova za provjeru

Prije nego dodate drugi sloj šifriranja VPN-u, iskreno odgovorite na jedno pitanje: šta posmatrač i dalje drži nakon što oba sloja obave svoj posao? Ako je odgovor unutrašnji šifrat, nepromijenjen, onda je ugnježđivanje kupilo vrijeme i ništa drugo. Ono što slijedi je postupak odlučivanja, a ne preporuka. Isti dijagram je protraćen procesor u jednom postavljanju i tačan odgovor u drugom, a samo tri uslova razdvajaju to dvoje.

Zapišite šta posmatrač zadržava

Zapišite objekat koji protivnik danas može sačuvati, a zatim slijed uklanjanja koji bi na kraju otkrio otvoreni tekst. Spoljni tunel proizvodi šifrat; kada njegova zaštita završi, ostaje šifrat unutrašnjeg tunela, još uvijek zapečaćen. Ukloniti omotač nije dešifrovanje. Ta rečenica opisuje ugnježđivanje i vrijedi samo dok unutrašnji ključ preživljava. U trenutku kada dva sloja bilo šta dijele, vremenska linija se sažima u jedan događaj.

Dakle, koristan artefakt je vremenska linija, a ne dijagram kutija. Za svaki sloj zapišite krajnju tačku, vlasnika ključa, provjeru identiteta i godinu u kojoj se očekuje da pretpostavka padne.

Praktičan način da provjerite vlastitu tvrdnju: pretpostavite da posmatrač snima sve i nikada ne odustaje. Pod tom pretpostavkom, štiti li dizajn još uvijek korisni teret tokom potrebnog roka? Ako odgovor zavisi od toga da posmatrač odluči ne skladištiti saobraćaj, dizajn nema odgovor.

Uslov prvi: zaustavljaju li se slojevi na različitim mjestima?

Ugnježđivanje se isplati kada dva sloja završavaju u različitim domenima povjerenja, na primjer IPsec mrežni prolaz kojim upravlja provajder ispred tunela na aplikacijskom nivou koji završava unutar vaše mreže. Tada probijanje spoljnog sloja daje šifrat koji samo vaš host može otvoriti, a provajder nikada ne vidi otvoreni tekst. Stavite oba sloja na isti mrežni prolaz i to svojstvo nestaje. Ko kompromituje kutiju, čita saobraćaj između dvije operacije dešifrovanja, koliko god omotača dijagram pokazivao.

Provjerite to instaliranim stanjem, a ne dizajnom. Na Linuxu ip xfrm state navodi svaku sigurnosnu asocijaciju i njene krajnje tačke, što određuje gdje se svaki sloj zaista zaustavlja.

Uslov drugi: je li ključni materijal zaista nezavisan?

Dva sloja izgrađena od jednog sertifikata, jednog unaprijed dijeljenog ključa ili jedne biblioteke dobavljača su jedan sloj s dodatnim koracima. Tada jedno kompromitovano uvjerenje otključava oba, a jedna greška u implementaciji uklanja oba odjednom. Nezavisnost mora biti vidljiva u konfiguraciji, a ne tvrđena na slajdu.

Tu hibridno uspostavljanje ključeva nadmašuje slaganje tunela. IKEv2 može nositi nekoliko razmjena ključeva u jednom pregovaranju, pa klasična grupa i postkvantni KEM mogu oba hraniti iste ključeve sesije umjesto da budu namotani jedan oko drugog. Rezultat je jedna sigurnosna asocijacija čiji ključevi zavise od obje tajne, a napadač mora razbiti obje. To je dokumentovana konstrukcija s definisanim sastavom, što domaći stog od dva VPN proizvoda nije. Na strongSwanu swanctl --list-sas ispisuje pregovarani predlog za svaku SA, i tako potvrđujete šta je stvarno radilo, a ne šta ste konfigurisali.

Uslov treći: nadživljavaju li podaci spoljnu pretpostavku?

Sloj koji mora izdržati dvadeset godina treba dvadesetogodišnji argument. Snimiti sada i dešifrovati kasnije je jeftino, i to je razlog zašto se klasičan spoljni sloj ne može tretirati kao privremeni omotač oko nečeg jačeg.

Pitajte kada svaki ključ postaje obnovljiv, a ne je li šifra razbijena danas. Statična razmjena ključeva bez tajnosti prema naprijed pada retroaktivno onog dana kada privatni ključ padne. Efemerna razmjena ključeva pada samo za sesije koje napadač može napasti dok su žive, ili kada sam algoritam oslabi. Ta razlika odlučuje hoće li unutrašnji sloj još pomoći 2040. Ona takođe odlučuje mijenja li spoljni sloj uopšte bilo šta, jer spoljni sloj s kraćim životom ključa jednostavno postaje najranija tačka na vremenskoj liniji.

Šta umjesto toga izgraditi kada je odgovor ne

Ako bilo koji od tri uslova padne, odbacite ugnježđivanje i uložite trud u sloj koji stvarno nosi zahtjev za rokom. Konfigurišite hibridnu razmjenu ključeva u protokolu koji već pokrećete, održavajte implementaciju ažurnom i zapišite sastav na koji se oslanjate. Navesti ML-KEM u projektnom dokumentu nije sigurnosno svojstvo, a FIPS 203 definiše mehanizam inkapsulacije ključeva, ne vaš tunel.

Gdje drugi sloj zaista zaslužuje svoje mjesto, opišite ga kao odbranu u dubinu, a ne kao dokaz. Zatim provjerite sastav: koja krajnja tačka drži koji ključ, koji identitet provjerava svaka strana i šta operater s pristupom konzoli može pročitati. Dizajn koji preživi ta tri pitanja vrijedi dodatni procesor. Onaj koji ne preživi samo je dijagram.

Prije prozora promjene zabilježite trenutnu SA tabelu i pregovarane predloge, nakon njega ih zabilježite ponovo i uporedite, jer jedini dokaz koji je bitan jeste ono na šta su se uređaji zaista dogovorili.