OpenVPN valdymo paketų sekimas: tls-auth prieš TLS

tls-auth gedimas paprastai pranešamas kaip rankos paspaudimo problema, nors niekada ja nebuvo. HMAC tikrinamas valdymo pakete prieš bet kokį TLS apdorojimą, todėl netinkamas raktas ar kryptis sukelia gedimą, kuris atrodo kaip sertifikato problema ir sprendžiamas dviem sluoksniais anksčiau. Voką traktuojant kaip atskirą objektą, diagnostika sutrumpėja: perskaitykite laukus, patvirtinkite, kad tikrinimas įvyksta anksti, tada palyginkite tris dalykus, dėl kurių abu galai turi sutarti.

Skaitykite voką tokia tvarka, kokia jis sukonstruotas

Valdymo paketas neša sesijos identifikatorių, neprivalomą tls-auth HMAC, pakartojimo ir patvirtinimo informaciją bei patikimą pranešimo identifikatorių, o po to ateina pranešimo tipo naudingoji apkrova. Kai pranešimas yra rankos paspaudimo pranešimas, naudingoji apkrova būna TLS šifruotas tekstas. Tai ir yra visas ryšys: TLS medžiaga keliauja pranešimo, kurį vokas jau saugo, viduje. Žr. OpenVPN tinklo protokolo nuorodą, kuri išvardija valdymo kanalo laukus ta tvarka.

Patikimumo sluoksnį lengva supainioti su kriptografija. Patvirtinimai, kartotinis siuntimas ir pranešimo identifikatorius egzistuoja tam, kad valdymo pranešimai atkeliautų vieną kartą ir tvarkingai per nepatikimą transportą. Tai nėra autentifikacija, o teisingas pranešimo identifikatorius nieko neįrodo apie tai, kas išsiuntė paketą.

Laikykite šį grupavimą konceptualių. Tai nėra baitų eilės diagrama ir nepakanka žymei apskaičiuoti, nes į HMAC patenkantys laukai priklauso nuo realizacijos, versijos ir režimo.

Parodykite, kad tikrinimas įvyksta prieš rankos paspaudimą

Gavėjas, turintis bendrą raktą, gali patikrinti HMAC ir iš karto atmesti suklastotą paketą, neskirdamas rankos paspaudimo būsenos ir neatlikdamas viešojo rakto darbo. Apsauga apima ir pradinius rankos paspaudimo paketus, todėl netinkamas raktas pasireiškia kaip nepavykęs ryšys, o ne kaip vėlyva autentifikacijos klaida.

Padidinkite demono išsamumą ir stebėkite valdymo kanalą, o ne tun įrenginį:

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

Ko ieškote, tai valdymo kanalo HMAC tikrinimo gedimas, praneštas paketo lygmeniu, prieš bet kokį TLS įspėjimą. TLS įspėjimas žurnale reiškia, kad vokas buvo priimtas ir gedimas persikėlė į vidų, o tai jau kitas tyrimas su kitu sprendimu.

Krypties apdorojimas taip pat yra čia. Kai statinis rakto failas naudojamas su tls-auth, abu galai ima priešingas rakto kryptis, o protokolas naudoja šį padalijimą, kad užfiksuotas paketas negalėtų būti atspindėtas atgal siuntėjui. Apvertus kryptį raktas lieka tas pats ir vis tiek kiekvienas paketas nepavyksta. Keiskite po vieną galą, tada paleiskite iš naujo abu demonus, kad pora būtų įkelta kartu.

Suderinkite raktą, kryptį ir digest abiejuose galuose

Trys reikšmės turi sutapti ir tik viena jų yra failas. Statinio rakto turinys turi būti identiškas abiejuose galuose, kryptis turi būti priešinga, o HMAC naudojamas digest turi atitikti. Patikrinkite konfigūraciją prieš liesdami rakto medžiagą, nes viena apversta kryptis paaiškina daugiau gedimų nei sugadintas failas:

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

Sugeneruokite bendrą paslaptį įrankiu, o ne redaktoriumi, ir laikykite teises griežtas:

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

Senseres versijos priimdavo šiek tiek kitokią parinkčių tvarką raktams generuoti, o toms versijoms rašyti profiliai vis dar cirkuliuoja. Sugeneruotas failas abiem atvejais yra to paties tipo objektas, todėl tikrinama, ar abu galai turi identiškus baitus, o ne kokia rašyba juos sukūrė.

Nepainiokite tls-auth su tls-crypt. Abu saugo valdymo kanalą, bet tls-crypt jį taip pat šifruoja ir slepia rankos paspaudimą nuo stebėtojų, ir pakeičia krypčių padalijimą savo rakto apdorojimu. Profilis, naudojantis vieną, neveiks su partneriu, sukonfigūruotu kitam, ir joks digest derinimas tos spragos neužpildo.

Atkurkite žymę tik iš tikrojo formato

Tikslus baitų atkūrimas yra atskira užduotis nuo VPN paleidimo, ir jis veikia tik su tikromis įvestimis: realizacija ir versija, kurios sukūrė paketą, pasirinktas digest, kryptis ir tikrieji baitai, įskaitant sesijos identifikatorių ir patvirtinimų masyvą. Tekstinis laukų sąrašo pateikimas nėra tie baitai.

Žymės ilgis išplaukia iš digest, todėl fiksuoto ilgio prielaida sugriūva tą akimirką, kai kas nors jį pakeičia. Maišykite paketą taip, kaip daro realizacija, o ne taip, kaip jį pateikia lentelė tinklaraščio įraše, ir lyginkite su to paties partnerio užfiksuotu įrašu, o ne su ranka išvestu lūkesčiu.

Laikykite šį pratimą toli nuo produkcijos profilių. Niekas žymės atkūrime nepasako, ar diegimas turėtų įjungti apsaugą.

Atšaukite neatitikimą nepašalindami apsaugos

Viliojantis bandymas yra ištrinti tls-auth, pamatyti, kad ryšys pavyksta, ir padaryti išvadą, kad raktas buvo neteisingas. Toks atsakymas kainuoja apsaugą ir nieko neišmoko apie tai, kuri iš trijų reikšmių nesutapo. Vietoj to paimkite patvirtintą atitinkančią konfigūraciją iš serverio pusės ir palyginkite su ja.

Paruoškite pakeitimą taip, kad jį būtų galima atšaukti. Išsaugokite ankstesnę serverio konfigūraciją ir rakto failą, pritaikykite pataisytą porą, patikrinkite, kad klientas užbaigia rankos paspaudimą, ir tik tada pašalinkite atsarginę kopiją. Jei klientams nepavyksta po pakeitimo, atkurkite ankstesnius failus, o ne improvizuokite trečią variantą sutrikimo metu. Atkūrimas turėtų būti viena komanda, kurią jau žinote prieš pradėdami.

Galiausiai prisiminkite, ką reiškia sėkmingas patikrinimas. Jis įrodo, kad partneris turi bendrą raktą, o ne tai, kad jo sertifikatas ar paskyra yra įgalioti, ir jis nieko nesako apie suderintą duomenų kanalo šifrą. Autorizacija ir duomenų apsauga nustatomos vėliau, todėl švarus voko patikrinimas yra atspirties taškas, o ne nuosprendis.