Ngjitja e një profili tls-crypt-v2 në një tiket duket e padëmshme derisa të numëroni çfarë përmban skedari. Çelësi i kanalit të kontrollit të klientit qëndron pranë një kopjeje të kriptuar të të njëjtit çelës, dhe një objekt i tretë, çelësi i mbështjelljes, nuk largohet kurrë nga serveri që pranon. Këta tre përgjigjen për pyetje të ndryshme rreth ruajtjes, ndarjes dhe tërheqjes. Ndarja e tyre zgjidh shumicën e debateve të politikës para se të fillojnë.

Çfarë përmban në të vërtetë profili

Gjysma e klientit e tls-crypt-v2 është një çelës plus një kopje e mbështjellë e tij. Klienti përdor çelësin e thjeshtë për mbrojtjen e kanalit të kontrollit dhe gjatë konfigurimit i dorëzon serverit kopjen e mbështjellë, kështu që serveri rikuperon të njëjtin çelës pa ruajtur një kopje në tekst të qartë për çdo klient. Çelësi i mbështjelljes e bën të mundur atë rikuperim dhe i takon vetëm palës që pranon. Çdo gjë më poshtë rrjedh nga vendi ku jetojnë këta tre objekte.

ObjectWhere it livesWhat can open itWhat a leak costs
Server wrapping keyaccepting servers onlythe unwrap step inside the serverevery wrapped copy issued to that group becomes readable
Wrapped client keyinside the client profilethe server wrapping keyit names a client and exposes its metadata, but not the key inside
Client control keyinside the client profile, usable as-isthe client that owns itsomeone can open handshakes as that client until the server refuses the key

Lexoni tabelën sipas ruajtjes, jo sipas emrit, dhe pasojat dalin vetë. Humbja e çelësit të mbështjelljes është ngjarja e shtrenjtë, sepse asgjë në një profil nuk mund ta rindërtojë atë dhe rikuperimi i ndershëm është riemitimi i grupit. Një profil i rrjedhur është më i lirë, por shumë më i zakonshëm, sepse njerëzit ngjitin profile në tiketa duke besuar se kopja e mbështjellë e bën skedarin të sigurt për ndarje. Dy dështimet kërkojnë përgjigje të ndryshme, dhe për këtë arsye objektet mbahen veçmas.

Pse kopja e mbështjellë nuk është e gjithë historia

Një profil mbart materialin e përdorshëm të klientit bashkë me homologun e tij të mbështjellë, kështu që mbrojtja e kopjes për serverin nuk thotë asgjë për mbrojtjen e skedarit. Blob-i është i sigurt për transmetim dhe jo i sigurt për publikim. Metadatat brenda tij janë të dukshme për këdo që merr blob-in, përfshirë këdo që më vonë lexon tiketën ku u ngjit.

Trajtojeni profilin si kredenciale, jo si shembull konfigurimi. Një skedar i rrjedhur i jep mbajtësit një identitet klienti funksional derisa serveri të ndalojë pranimin e atij identiteti, dhe mbështjellja nuk bën asgjë për atë dritare. Emetoni një profil për çdo klient, që tërheqja të mbetet një vendim për një skedar të vetëm, dhe bëni kopje rezervë të çelësit të mbështjelljes veçmas nga konfigurimi i serverit që ai mundëson. Asnjë nga dy zakonet nuk e riparon një profil të kompromentuar, por të dyja përcaktojnë sa shpejt do të përmbahet ai i radhës.

Ku qëndron grepi i verifikimit në shtrëngimin e duarve

Grepi i verifikimit ekzekutohet përpara se stiva TLS të ekspozohet, dhe detyra e tij është të inspektojë metadatat e mbartura në blob-in e mbështjellë. Ai merr ato metadatat plus një mjedis të vogël, të dokumentuar, dhe ka më pak material për të punuar sesa një grep autentikimi. Të supozohet se sheh emra përdoruesish, gjendje sesioni ose variabla shtojcash është mënyra e zakonshme se si ky grep shkruhet keq. Lexoni seksionin e manualit të vetë grepit në vend që të huazoni pritshmëri nga një grep tjetër.

Statusi i daljes është vendimi: një rezultat jo zero e refuzon klientin dhe një rezultat zero e lë shtrëngimin e duarve të vazhdojë. Prandaj politika duhet të thotë çfarë ndodh kur metadatat mungojnë, nuk mund të analizohen ose janë të papritura. Shkruani fillimisht rrugën e refuzimit, pastaj vendosni cilat vlera janë të pranueshme.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Ato dy rreshta janë sipërfaqja e politikës në server: njëri emërton çelësin e mbështjelljes, tjetri emërton programin që gjykon çdo klient. Gjithçka interesante jeton në skript, i cili meriton kontroll versioni dhe të njëjtin shqyrtim si çdo rregull tjetër aksesi.

Llogaria, certifikata dhe çelësi i kontrollit tërhiqen veçmas

Pranimi i hershëm i kanalit të kontrollit nuk është autentikim, sepse ndodh përpara verifikimit të identitetit TLS dhe përpara çdo autorizimi llogarie. Çaktivizimi i një llogarie, revokimi i një certifikate dhe refuzimi i një çelësi kontrolli të klientit janë tre veprime me tre mekanizma. Një vendosje që kryen vetëm njërin prej tyre ka një boshllëk, jo një politikë. Pajtoni të tre me qëllim dhe regjistroni cili hap ushtron cilën autoritet.

Koha është dallimi i dytë. Një listë pranimi e ndryshuar vlen për shtrëngime të reja duarsh, ndërsa sesionet e krijuara tashmë vazhdojnë derisa diçka t'i përfundojë. Numërimi i hyrjeve në listën e re si provë që sesionet e vjetra përfunduan është mënyra se si një klient i hequr mbetet i lidhur për orë të tëra.

Autoritetet e papajtuara lënë dy vrima që gjenden lehtë në praktikë. Një llogari mund të çaktivizohet ndërsa çelësi i saj i kontrollit ende hap një shtrëngim duarsh, dhe një certifikatë mund të revokohet ndërsa politika e metadateve ende pranon të njëjtin klient. Të dyja janë i njëjti gabim në vende të ndryshme, sepse një operator e trajtoi një listë të vetme si të gjithë autoritetin. Vendosni tre listat krah për krah në momentin e heqjes dhe gabimi bëhet i dukshëm.

Emetimi dhe tërheqja e një profili

Emetimi është gjysma e lehtë: krijoni çelësin e klientit në palën që pranon, dorëzoni profilin saktësisht një pronari, mbani materialin e mbështjelljes të kufizuar dhe ekzekutoni të njëjtin program verifikimi në çdo server që pranon. Pranimi i lirë është veti e të gjithë grupit, jo e hostit më të re. Një server i dytë me skript më të vjetër ose më të lirshëm bëhet në heshtje rruga më e dobët në vendosje.

Tërheqja kërkon tre hapat në një rend të qëllimshëm. Refuzoni klientin në grepin e verifikimit që shtrëngimet e reja të dështojnë, revokoni certifikatën e tij nëse përdoret PKI dhe çaktivizoni llogarinë që autorizimi i mëvonshëm të mos ketë çfarë të autorizojë. Pastaj përfundoni sesionet që lejonte pranimi i vjetër, sepse ato nuk do të vënë re asnjë nga të tre. Ushtrojeni sekuencën në një klient që mund të përballoni ta thyeni.

Metadatat në një profil janë input për atë politikë, jo provë se kontrolli i aksesit ekziston tashmë. Dokumenti i projektimit të OpenVPN 2.6 përshkruan objektet dhe kufirin që ato tërheqin, ndërsa zbatimi mbetet te operatori.

Artikuj të ngjashëm