tls-auth kundrejt tls-crypt: çfarë mbron secila në OpenVPN

Të dyja opsionet përdorin një skedar të përbashkët çelësi dhe të dyja e bëjnë trafikun e shtrëngimit të duarve më të vështirë për t'u falsifikuar, prandaj trajtohen si dy emra të së njëjtës veçori. Nuk janë. Njëra nënshkruan paketat e kontrollit, tjetra i kripton edhe ato, dhe asnjëra nuk ka lidhje me shifrën që mbron të dhënat e tua.

Ky dallim ka rëndësi kur një profil nuk lidhet dot, kur një rishikim sigurie pyet se çfarë mbron çelësi, dhe kur dikush supozon se skedari shtesë e bën tunelin të kriptuar në një mënyrë të pacaktuar.

Çfarë mbron në të vërtetë çelësi i përbashkët

Çelësi që përdorin këto opsione i përket kanalit të kontrollit: shkëmbimi që negocion parametrat, vërteton identitetet dhe nxjerr çelësat e të dhënave. Është një sekret i ndarë paraprakisht që të dy skajet duhet ta kenë përpara se shtrëngimi i duarve të vazhdojë. Meqenëse qëndron përpara verifikimeve të identitetit, një çelës i gabuar e ndal bisedën më herët sesa do ta bënte një fjalëkalim i gabuar. Ky rend shpjegon pse mënyra e dështimit është kaq e heshtur.

tls-auth e përdor atë sekret për të llogaritur një HMAC mbi paketat e kontrollit. Një paketë pa nënshkrim të vlefshëm hidhet poshtë përpara se të arrijë përpunimin më të kushtueshëm TLS, prandaj opsioni përshkruhet shpesh si filtri i parë dhe jo si zëvendësim i TLS.

tls-crypt shkon më tej duke kriptuar trafikun e mbrojtur të kontrollit përveç vërtetimit të tij. Përmbajtja e certifikatave, emrat e shifrave të negociuara dhe detaje të tjera të shtrëngimit nuk janë më të dukshme në rrjet, dhe një vëzhgues pa çelësin as nuk mund të shohë çfarë versioni TLS po provohet. Për një instalim që ka frikë të zbulojë gjurmën e tij VPN, ajo veti është arsyeja kryesore për ta zgjedhur. Megjithatë mbetet një sekret grupi, jo një kredencial për çdo përdorues.

Asnjë mekanizëm nuk lëshon identitete. Çelësi i përbashkët është një sekret grupi, dhe kushdo që e ka mund të përmbushë atë shtresë të verifikimit.

Ku ndryshojnë dy opsionet

Dallimi i dukshëm është çfarë sheh një vëzhgues. Me tls-auth shtrëngimi i duarve është i dukshëm, por nuk verifikohet pa çelësin. Me tls-crypt shtrëngimi i duarve është i errët për këdo që nuk e ka çelësin.

Edhe konfigurimi ndryshon. tls-auth përdoret me një vlerë drejtimi, kështu që njëra anë përdor gjysmën e materialit të çelësit dhe ana tjetër gjysmën tjetër. tls-crypt përdor një çelës të vetëm në të dy drejtimet, prandaj direktiva e drejtimit nuk është pjesë e skemës së tij.

Në versionet moderne dy opsionet përjashtojnë njëra-tjetrën. Profili duhet të mbajë njërën prej tyre, jo të dyja, dhe serveri e klienti duhet të bien dakord se cila, me material çelësi identik. Mbajtja e një direktive të vjetër pranë një të reje është një mbetje e zakonshme migrimi. Hiq atë joaktive që lexuesi tjetër të dijë cila shtresë është në fuqi.

Një variant më i ri, tls-crypt-v2, lidh çdo klient me çelësin e tij të mbështjellë, kështu që revokimi i një klienti nuk kërkon rishpallje të çelësit të grupit. Ia vlen ta njohësh, por është opsion tjetër dhe nuk është sinonim i asnjërës prej dyve këtu.

Pse një mospërputhje duket sikur nuk ndodh asgjë

Kur materiali i përbashkët nuk përputhet, pala tjetër i hedh poshtë paketat pa i thënë dërguesit pse. Nuk ka gabim vërtetimi për të lexuar, sepse paketa nuk arriti kurrë në shtresën që do ta krijonte.

Klienti provon përsëri, serveri nuk thotë asgjë, dhe simptoma duket si problem rrjeti. Atëherë njerëzit rinisin shërbimin, shkruajnë përsëri fjalëkalimin e llogarisë, ose heqin direktivën e mbrojtjes për ta «testuar», gjë që ndryshon instalimin në vend që ta diagnostikojë.

Lexo në regjistrin e serverit ankesën e parë në nivel pakete, jo rreshtin e fundit të riprovimit. Konfirmo se të dyja palët mbajnë të njëjtin opsion me material çelësi identik dhe se skedari i çelësit nuk u rigjenerua vetëm në njërën anë.

Heqja e direktivës nuk është riparim i sigurt. Ajo çaktivizon një shtresë mbrojtjeje për çdo klient, dhe një tunel që funksionon më pas dëshmon vetëm se ajo shtresë ishte mospërputhja.

Çfarë duhet ende konfiguruar veçmas

Këto opsione nuk verifikojnë kush është pala tjetër. Verifikimi i certifikatave, ankorimi i besimit dhe emri i pritur i serverit mbeten kërkesa të veçanta, dhe asnjëra nuk bëhet opsionale për shkak të pranisë së një çelësi të përbashkët.

Ato gjithashtu nuk zgjedhin shifrën e të dhënave. Ai është një negociim i veçantë i kontrolluar nga cilësimet e kanalit të të dhënave në të dyja palët, dhe një tunel i mbrojtur me tls-crypt mund të përdorë ende një shifër që nuk e ke dashur.

Së fundi, vetë çelësi i përbashkët kërkon trajtim. Trajtoje si sekret, shpërndaje përmes një kanali të miratuar dhe zëvendësoje kur largohet kushdo që e kishte. Meqenëse është i përbashkët, ekspozimi i tij është ekspozimi i çdo skaji që e përdor.