OpenVPN vadības pakešu izsekošana: tls-auth pirms TLS

tls-auth kļūme parasti tiek ziņota kā rokas paspiešanas problēma, lai gan tā nekad nav bijusi. HMAC tiek pārbaudīts vadības pakešu līmenī pirms jebkādas TLS apstrādes, tāpēc neatbilstoša atslēga vai virziens rada kļūmi, kas izskatās kā sertifikāta problēma un tiek izlemta divus slāņus agrāk. Ja aploksni uztver kā atsevišķu objektu, diagnostika kļūst īsa: izlasiet laukus, pārliecinieties, ka pārbaude notiek agri, un pēc tam salīdziniet trīs lietas, par kurām abām pusēm jāvienojas.

Lasiet aploksni tādā secībā, kādā tā tiek veidota

Vadības pakete nes sesijas identifikatoru, neobligāto tls-auth HMAC, atkārtošanas un apstiprinājuma informāciju un uzticamu ziņojuma identifikatoru, un pēc tam nāk ziņojuma tipa kravnesa. Kad ziņojums ir rokas paspiešanas ziņojums, kravnesa ir TLS šifrēts teksts. Tā ir visa saistība: TLS materiāls ceļo ziņojumā, ko aploksne jau aizsargā. Skatiet OpenVPN tīkla protokola uzziņu, kurā vadības kanāla lauki uzskaitīti šajā secībā.

Uzticamības slāni viegli sajauc ar kriptogrāfiju. Apstiprinājumi, atkārtota sūtīšana un ziņojuma identifikators pastāv tāpēc, lai vadības ziņojumi nonāktu vienreiz un secībā pa neuzticamu transportu. Tie nav autentifikācija, un pareizs ziņojuma identifikators neko nepierāda par to, kas nosūtīja paketi.

Uztveriet šo grupējumu kā konceptuālu. Tā nav baitu secības diagramma, un ar to nepietiek, lai aprēķinātu birku, jo lauki, kas nonāk HMAC, ir atkarīgi no ieviešanas, versijas un režīma.

Parādiet, ka pārbaude notiek pirms rokas paspiešanas

Uztvērējs ar koplietoto atslēgu var pārbaudīt HMAC un nekavējoties izmest vilto paketi, nepiešķirot rokas paspiešanas stāvokli un neveicot publiskās atslēgas darbu. Aizsardzība aptver arī sākotnējās rokas paspiešanas paketes, un tieši tāpēc nepareiza atslēga parādās kā neizdevies savienojums, nevis kā vēla autentifikācijas kļūda.

Palieliniet dēmona detalizāciju un vērojiet vadības kanālu, nevis tun ierīci:

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

Tas, ko meklējat, ir vadības kanāla HMAC pārbaudes kļūme, kas ziņota pakešu līmenī, pirms jebkāda TLS brīdinājuma. TLS brīdinājums žurnālā nozīmē, ka aploksne tika pieņemta un kļūme pārcēlās uz iekšu, kas ir cita izmeklēšana ar citu risinājumu.

Virziena apstrāde arī ir šeit. Kad statiska atslēgas datne tiek lietota ar tls-auth, abas puses izmanto pretējus atslēgas virzienus, un protokols izmanto šo sadalījumu, lai notvertu paketi nevarētu atstarot atpakaļ tās sūtītājam. Virziena apgriešana atstāj atslēgu identisku un tomēr ikviena pakete neizdodas. Mainiet pa vienai pusei, pēc tam restartējiet abus dēmonus, lai pāris ielādētos kopā.

Saskaņojiet atslēgu, virzienu un digest abās pusēs

Trim vērtībām jāsakrīt, un tikai viena no tām ir datne. Statiskās atslēgas saturam jābūt identiskam abās pusēs, virzienam jābūt pretējam, un HMAC izmantotajam digest jāsakrīt. Pārbaudiet konfigurāciju pirms atslēgas materiāla aiztikšanas, jo viens apgriezts virziens izskaidro vairāk kļūmju nekā bojāta datne:

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

Ģenerējiet koplietoto noslēpumu ar rīku, nevis redaktoru, un turiet atļaujas stingras:

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

Vecākas versijas pieņēma nedaudz citādu opciju secību atslēgu ģenerēšanai, un šīm versijām rakstītie profili joprojām cirkulē. Ģenerētā datne abos gadījumos ir viena tipa objekts, tāpēc pārbaude ir par to, vai abās pusēs ir identiski baiti, nevis par to, kura rakstība tos radīja.

Nejauciet tls-auth ar tls-crypt. Abi aizsargā vadības kanālu, bet tls-crypt to arī šifrē un slēpj rokas paspiešanu no novērotājiem, un aizstāj virzienu sadalījumu ar savu atslēgu apstrādi. Profils, kas lieto vienu, nesadarbosies ar partneri, kas konfigurēts otram, un nekāda digest pielāgošana šo plaisu neaizpilda.

Atveidojiet birku tikai no īstā formāta

Precīza baitu atveide ir atsevišķs uzdevums no VPN darbināšanas, un tā darbojas tikai ar īstajām ievadēm: ieviešanu un versiju, kas izveidoja paketi, izvēlēto digest, virzienu un faktiskajiem baitiem, ieskaitot sesijas identifikatoru un apstiprinājumu masīvu. Lauku saraksta teksta atveide nav tie baiti.

Birkas garums izriet no digest, tāpēc pieņēmums par fiksētu garumu sabrūk tajā brīdī, kad kāds to maina. Jaucēt paketi tā, kā to dara ieviešana, nevis tā, kā to attēlo tabula emuāra ierakstā, un salīdziniet ar ierakstu, kas ņemts no tā paša partnera, nevis ar manuāli izsecinātu gaidījumu.

Turiet šo vingrinājumu tālu no ražošanas profiliem. Nekas birkas atveidē nepasaka, vai izvietojumam jāieslēdz aizsardzība.

Atsauciet neatbilstību, nenoņemot aizsardzību

Kārdinošais tests ir izdzēst tls-auth, redzēt, ka savienojums izdodas, un secināt, ka atslēga bija nepareiza. Šāda atbilde maksā aizsardzību un neiemāca neko par to, kura no trim vērtībām neatbilda. Tā vietā iegūstiet apstiprināto atbilstošo konfigurāciju no servera puses un salīdziniet ar to.

Sagatavojiet izmaiņas tā, lai tās būtu atgriežamas. Saglabājiet iepriekšējo servera konfigurāciju un atslēgas datni, piemērojiet laboto pāri, pārbaudiet, ka klients pabeidz rokas paspiešanu, un tikai pēc tam noņemiet dublējumu. Ja klientiem pēc izmaiņām neizdodas, atjaunojiet iepriekšējās datnes, nevis improvizējiet trešo variantu pārtraukuma laikā. Atjaunošanai jābūt vienai komandai, ko jau zināt pirms sākšanas.

Visbeidzot, atcerieties, ko nozīmē izturēta pārbaude. Tā pierāda, ka partnerim ir koplietotā atslēga, nevis to, ka viņa sertifikāts vai konts ir autorizēts, un tā neko nesaka par saskaņoto datu kanāla šifru. Autorizācija un datu aizsardzība tiek izveidota vēlāk, tāpēc tīra aploksnes pārbaude ir sākumpunkts, nevis spriedums.