Gjurmimi i paketave të kontrollit të OpenVPN: tls-auth para TLS

Një dështim i tls-auth raportohet zakonisht si problem i shtrëngimit të duarve, ndërsa nuk ka qenë kurrë i tillë. HMAC kontrollohet në paketën e kontrollit përpara çdo përpunimi TLS, kështu që një çelës ose drejtim i papërputhshëm prodhon një dështim që duket si problem certifikate dhe vendoset dy shtresa më parë. Trajtimi i zarfit si objekt më vete e shkurton diagnozën: lexoni fushat, konfirmoni që kontrolli ndodh herët, pastaj krahasoni tre gjërat për të cilat të dy skajet duhet të bien dakord.

Lexoni zarfin sipas rendit në të cilin ndërtohet

Një paketë kontrolli mbart një identifikues sesioni, HMAC-in opsional të tls-auth, informacion përsëritjeje dhe konfirmimi, dhe një identifikues të besueshëm mesazhi, dhe pastaj vjen ngarkesa e llojit të mesazhit. Kur mesazhi është mesazh shtrëngimi duarsh, ngarkesa është rastësisht tekst i shifruar TLS. Kjo është e gjithë lidhja: materiali TLS udhëton brenda një mesazhi që zarfi e mbron tashmë. Shihni referencën e protokollit të rrjetit të OpenVPN që rendit fushat e kanalit të kontrollit në atë rend.

Shtresa e besueshmërisë ngatërrohet lehtë me kriptografinë. Konfirmimet, ridërgimi dhe identifikuesi i mesazhit ekzistojnë që mesazhet e kontrollit të mbërrijnë një herë dhe sipas radhës përmes një transporti jo të besueshëm. Ato nuk janë vërtetim, dhe një identifikues i saktë mesazhi nuk provon asgjë për atë se kush e dërgoi paketën.

Mbajeni këtë grupim si koncept. Nuk është diagram i rendit të bajteve dhe nuk mjafton për të llogaritur një etiketë, sepse fushat që hyjnë në HMAC varen nga zbatimi, versioni dhe mënyra.

Tregoni që kontrolli ndodh përpara shtrëngimit të duarve

Një marrës që mban çelësin e përbashkët mund të verifikojë HMAC-in dhe ta hedhë menjëherë një paketë të falsifikuar, pa ndarë gjendje shtrëngimi duarsh ose pa bërë punë me çelës publik. Mbrojtja mbulon edhe paketat fillestare të shtrëngimit të duarve, dhe pikërisht për këtë një çelës i gabuar shfaqet si lidhje e dështuar dhe jo si gabim i vonuar vërtetimi.

Rritni fjalosjen e daemon-it dhe vëzhgoni kanalin e kontrollit në vend të pajisjes tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Ajo që kërkoni është një dështim i verifikimit HMAC të kanalit të kontrollit i raportuar në nivel pakete, para çdo alarmi TLS. Një alarm TLS në regjistër do të thotë që zarfi u pranua dhe dështimi u zhvendos nga brenda, që është një hetim tjetër me një zgjidhje tjetër.

Trajtimi i drejtimit ndodhet gjithashtu këtu. Kur një skedar çelësi statik përdoret me tls-auth, dy skajet marrin drejtime çelësi të kundërta, dhe protokolli e përdor atë ndarje që një paketë e kapur të mos mund të reflektohet mbrapsht te dërguesi i saj. Kthimi i drejtimit e mban çelësin identik dhe prapë dështon çdo paketë. Ndryshoni një skaj në një herë, pastaj rinisni të dy daemon-ët që çifti të ngarkohet bashkë.

Përputhni çelësin, drejtimin dhe digest në të dy skajet

Tre vlera duhet të përputhen dhe vetëm njëra prej tyre është skedari. Përmbajtja e çelësit statik duhet të jetë identike në të dy skajet, drejtimi duhet të jetë i kundërt, dhe digest-i i përdorur për HMAC-in duhet të përputhet. Kontrolloni konfigurimin përpara se të prekni materialin e çelësit, sepse një drejtim i kthyer shpjegon më shumë dështime sesa një skedar i dëmtuar:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Gjeneroni sekretin e përbashkët me mjetin dhe jo me një redaktues, dhe mbajini lejet të rrepta:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Versionet e vjetra pranonin një rend opsionesh paksa të ndryshëm për gjenerimin e çelësave, dhe profilet e shkruara për ato versione qarkullojnë ende. Skedari i gjeneruar është i njëjti lloj objekti në të dyja rastet, kështu që kontrolli është nëse të dy skajet mbajnë bajte identike, jo cila drejtshkrim i prodhoi ato.

Mos e ngatërroni tls-auth me tls-crypt. Të dyja mbrojnë kanalin e kontrollit, por tls-crypt e shifron gjithashtu dhe e fsheh shtrëngimin e duarve nga vëzhguesit, dhe e zëvendëson ndarjen e drejtimeve me trajtimin e vet të çelësave. Një profil që përdor njërën nuk do të ndërveprojë me një palë të konfiguruar për tjetrën, dhe asnjë rregullim i digest-it nuk e mbyll atë hendek.

Riprodhoni një etiketë vetëm nga formati i vërtetë

Riprodhimi i saktë në bajt është detyrë e veçantë nga drejtimi i një VPN, dhe funksionon vetëm me hyrjet e vërteta: zbatimi dhe versioni që ndërtuan paketën, digest-i i zgjedhur, drejtimi dhe bajtet aktuale, përfshirë identifikuesin e sesionit dhe grupin e konfirmimeve. Një paraqitje tekstuale e listës së fushave nuk janë ato bajte.

Gjatësia e etiketës rrjedh nga digest-i, kështu që supozimi i një gjatësie fikse thyhet në momentin kur dikush e ndryshon atë. Hashni paketën ashtu siç bën zbatimi, jo ashtu siç e paraqet një tabelë në një postim blogu, dhe krahasoni me një kapje të marrë nga e njëjta palë, jo me një pritje të nxjerrë me dorë.

Mbajeni këtë ushtrim larg profileve të prodhimit. Asgjë në riprodhimin e një etikete nuk ju thotë nëse një vendosje duhet të aktivizojë mbrojtjen.

Ktheni një mospërputhje pa hequr mbrojtjen

Testi joshës është të fshini tls-auth, të shihni lidhjen të ketë sukses dhe të përfundoni se çelësi ishte i gabuar. Ajo përgjigje ju kushton mbrojtjen dhe nuk mëson asgjë për atë se cila nga tre vlerat nuk përputhej. Në vend të kësaj, merrni konfigurimin përputhës të miratuar nga ana e serverit dhe krahasoni me të.

Përgatitni ndryshimin që të jetë i kthyeshëm. Ruani konfigurimin dhe skedarin e çelësit të mëparshëm të serverit, aplikoni çiftin e korrigjuar, verifikoni që një klient përfundon shtrëngimin e duarve, dhe vetëm atëherë hiqni kopjen rezervë. Nëse klientët dështojnë pas ndryshimit, rikthejini skedarët e mëparshëm në vend që të improvizoni një variant të tretë gjatë një ndërprerjeje. Rikthimi duhet të jetë një komandë që ju tashmë e njihni përpara se të filloni.

Së fundi, mbani mend çfarë do të thotë një kontroll i kaluar. Provon që pala mban çelësin e përbashkët, jo se certifikata ose llogaria e saj është e autorizuar, dhe nuk thotë asgjë për shifrën e negociuar të kanalit të të dhënave. Autorizimi dhe mbrojtja e të dhënave vendosen më vonë, kështu që një kontroll i pastër i zarfit është pikënisje dhe jo verdikt.