A duhet të grumbulloni dy shtresa VPN? Tre kushte për t'u kontrolluar

Përpara se të shtoni një shtresë të dytë kriptimi në një VPN, përgjigjuni me ndershmëri një pyetjeje: çfarë mban ende vëzhguesi pasi të dy shtresat kanë bërë punën e tyre? Nëse përgjigjja është teksti i shifruar i brendshëm, i pandryshuar, atëherë folezimi bleu kohë dhe asgjë tjetër. Ajo që vijon është një procedurë vendimi, jo një rekomandim. I njëjti diagram është CPU e shpenzuar në një vendosje dhe përgjigjja e saktë në një tjetër, dhe vetëm tre kushte i ndajnë të dyja.

Shkruani çfarë ruan vëzhguesi

Regjistroni objektin që një kundërshtar mund të ruajë sot, dhe më pas sekuencën e heqjeve që përfundimisht do të ekspozonte tekstin e qartë. Një tunel i jashtëm prodhon tekst të shifruar; kur mbaron mbrojtja e tij, ajo që mbetet është teksti i shifruar i tunelit të brendshëm, ende i vulosur. Heqja e një mbështjelljeje nuk është dekriptim. Ai fjali përshkruan folezimin dhe vlen vetëm sa kohë çelësi i brendshëm mbijeton. Në momentin që dy shtresat ndajnë çdo gjë, vija kohore shembet në një ngjarje të vetme.

Pra, artefakti i dobishëm është një vijë kohore, jo një diagram kutish. Për secilën shtresë, shkruani pikën e fundit, pronarin e çelësit, kontrollin e identitetit dhe vitin në të cilin pritet të dështojë supozimi.

Një mënyrë praktike për të testuar pohimin tuaj: supozoni se vëzhguesi regjistron gjithçka dhe nuk dorëzohet kurrë. Sipas këtij supozimi, a e mbron ende dizajni ngarkesën për jetëgjatësinë e kërkuar? Nëse përgjigjja varet nga zgjedhja e vëzhguesit për të mos ruajtur trafik, dizajni nuk ka përgjigje.

Kushti një: a ndalen shtresat në vende të ndryshme?

Folezimi ia vlen kur dy shtresat përfundojnë në domene besimi të ndryshme, për shembull një portë IPsec e menaxhuar nga ofruesi përpara një tuneli në nivel aplikacioni që përfundon brenda rrjetit tuaj. Atëherë thyerja e shtresës së jashtme jep tekst të shifruar që vetëm hosti juaj mund ta hapë, dhe ofruesi nuk e sheh kurrë tekstin e qartë. Vendosni të dyja shtresat në të njëjtën portë dhe ajo veti zhduket. Kush komprometon kutinë lexon trafikun mes dy operacioneve të dekriptimit, sado mbështjellje të tregojë diagrami.

Kontrollojeni këtë me gjendjen e instaluar dhe jo me dizajnin. Në Linux, ip xfrm state liston çdo shoqatë sigurie dhe pikat e saj fundore, gjë që përcakton se ku ndalet në të vërtetë secila shtresë.

Kushti dy: a është materiali i çelësave vërtet i pavarur?

Dy shtresa të ndërtuara nga një certifikatë, një çelës i para-ndarë ose një bibliotekë e një furnizuesi janë një shtresë me hapa shtesë. Atëherë një kredencial i komprometuar hap të dyja, dhe një gabim implementimi i heq të dyja përnjëherë. Pavarësia duhet të jetë e dukshme në konfigurim, jo e pohuar në një slajd.

Këtu vendosja hibride e çelësave ia kalon grumbullimit të tuneleve. IKEv2 mund të mbajë disa shkëmbime çelësash në një negociatë, kështu që një grup klasik dhe një KEM pas-kuantik mund të dy të ushqejnë të njëjtët çelësa sesioni në vend që të mbështillen rreth njëri-tjetrit. Rezultati është një shoqatë e vetme sigurie, çelësat e së cilës varen nga të dy sekretet, dhe sulmuesi duhet të thyejë të dyja. Kjo është një ndërtim i dokumentuar me përbërje të përcaktuar, gjë që nuk është një grumbull shtëpiak i dy produkteve VPN. Në strongSwan, swanctl --list-sas shtyp propozimin e negociuar për çdo SA, dhe kështu konfirmoni çfarë funksionoi vërtet, jo çfarë konfiguruat.

Kushti tre: a i mbijetojnë të dhënat supozimit të jashtëm?

Një shtresë që duhet të durojë njëzet vjet kërkon një argument njëzetvjeçar. Regjistrimi tani dhe dekriptimi më vonë është i lirë, dhe për këtë arsye një shtresë e jashtme klasike nuk mund të trajtohet si mbështjellje e përkohshme rreth diçkaje më të fortë.

Pyetni kur bëhet i rikuperueshëm secili çelës, jo nëse shifra është thyer sot. Një shkëmbim statik çelësash pa sekretësi përpara dështon në mënyrë retrospektive ditën kur bie çelësi privat. Marrëveshja efemere e çelësave dështon vetëm për sesionet që një sulmues mund t'i sulmojë ndërsa janë të gjalla, ose kur vetë algoritmi dobësohet. Ai ndryshim vendos nëse një shtresë e brendshme ndihmon ende në 2040. Ai vendos gjithashtu nëse shtresa e jashtme ndryshon ndonjë gjë, sepse një shtresë e jashtme me jetëgjatësi më të dobët të çelësit thjesht bëhet pika më e hershme në vijën kohore.

Çfarë të ndërtohet në vend të kësaj kur përgjigjja është jo

Nëse dështon ndonjë nga tre kushtet, hiqni dorë nga folezimi dhe shpenzoni përpjekjen në shtresën që mban vërtet kërkesën e jetëgjatësisë. Konfiguroni një shkëmbim hibrid çelësash në protokollin që tashmë ekzekutoni, mbani implementimin aktual dhe shkruani përbërjen në të cilën mbështeteni. Përmendja e ML-KEM në një dokument dizajni nuk është veti sigurie, dhe FIPS 203 përcakton mekanizmin e inkapsulimit të çelësave, jo tunelin tuaj.

Aty ku një shtresë e dytë vërtet e fiton vendin e saj, përshkruajeni si mbrojtje në thellësi dhe jo si provë. Më pas verifikoni përbërjen: cila pikë fundore mban cilin çelës, çfarë identiteti kontrollon secila anë dhe çfarë mund të lexojë një operator me akses në konsolë. Një dizajn që i kalon këto tre pyetje ia vlen CPU-ja shtesë. Një që nuk i kalon është thjesht një diagram.

Përpara dritares së ndryshimit, kapni tabelën aktuale SA dhe propozimet e negotuara, dhe pas saj kapini përsëri dhe krahasoni, sepse e vetmja provë që ka rëndësi është ajo për të cilën pajtohen vërtet pajisjet.