Sledenje krmilnim paketom OpenVPN: tls-auth pred TLS
HMAC tls-auth sedi na krmilni ovojnici, ne znotraj rokovanja TLS. Uskladite ključ, smer in digest, nato preverite, ne da bi odstranili zaščito.
Napaka tls-auth se običajno prijavi kot težava rokovanja, čeprav to ni bila nikoli. HMAC se preveri na krmilnem paketu, preden se zgodi kakršna koli obdelava TLS, zato neujemajoč ključ ali smer povzroči napako, ki je videti kot težava s potrdilom in se odloči dve plasti prej. Če ovojnico obravnavamo kot samostojen objekt, je diagnoza kratka: preberite polja, potrdite, da se preverjanje zgodi zgodaj, nato primerjajte tri stvari, o katerih se morata oba konca strinjati.
Beri ovojnico v vrstnem redu, v katerem je zgrajena
Krmilni paket nosi identifikator seje, neobvezni HMAC tls-auth, podatke o ponavljanju in potrditvi ter zanesljiv identifikator sporočila, za tem pa sledi tovor vrste sporočila. Ko je sporočilo sporočilo rokovanja, je tovor po naključju šifrirano besedilo TLS. To je celotna povezava: material TLS potuje znotraj sporočila, ki ga ovojnica že varuje. Glejte referenco omrežnega protokola OpenVPN ki našteva polja krmilnega kanala v tem vrstnem redu.
Plast zanesljivosti zlahka zamenjamo s kriptografijo. Potrditve, ponovno pošiljanje in identifikator sporočila obstajajo zato, da krmilna sporočila prispejo enkrat in v vrstnem redu po nezanesljivem prenosu. Niso preverjanje pristnosti in pravilen identifikator sporočila ne dokaže ničesar o tem, kdo je poslal paket.
To združevanje obdržite kot pojem. Ni diagram vrstnega reda bajtov in ne zadostuje za izračun oznake, ker so polja, ki vstopajo v HMAC, odvisna od izvedbe, različice in načina.
Pokažite, da se preverjanje zgodi pred rokovanjem
Prejemnik, ki ima skupni ključ, lahko preveri HMAC in ponarejen paket takoj zavrže, ne da bi dodelil stanje rokovanja ali opravil delo z javnim ključem. Zaščita pokriva tudi začetne pakete rokovanja, zato se napačen ključ pokaže kot neuspešna povezava in ne kot pozna napaka preverjanja pristnosti.
Povečajte podrobnost demona in opazujte krmilni kanal namesto naprave tun:
openvpn --config /etc/openvpn/server.conf --verb 6
Iščete neuspeh preverjanja HMAC krmilnega kanala, sporočen na ravni paketa, pred kakršnim koli opozorilom TLS. Opozorilo TLS v dnevniku pomeni, da je bila ovojnica sprejeta in da se je napaka premaknila navznoter, kar je druga preiskava z drugo rešitvijo.
Tudi obravnava smeri je tukaj. Ko se statična ključna datoteka uporablja s tls-auth, dva konca zavzameta nasprotni smeri ključa in protokol uporablja to delitev, da zajetega paketa ni mogoče odbiti nazaj k pošiljatelju. Obrnjena smer ohrani ključ enak in vseeno vsak paket spodleti. Spreminjajte eno stran naenkrat, nato znova zaženite oba demona, da se par naloži skupaj.
Uskladite ključ, smer in digest na obeh koncih
Tri vrednosti se morajo ujemati in samo ena od njih je datoteka. Vsebina statičnega ključa mora biti na obeh koncih enaka, smer mora biti nasprotna, digest, uporabljen za HMAC, pa se mora ujemati. Preverite konfiguracijo, preden se dotaknete ključnega materiala, ker ena obrnjena smer pojasni več napak kot poškodovana datoteka:
grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf
Ustvarite skupno skrivnost z orodjem in ne z urejevalnikom, dovoljenja pa naj bodo stroga:
openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key
Starejše izdaje so sprejemale nekoliko drugačen vrstni red možnosti za ustvarjanje ključev in profili, napisani za te izdaje, še vedno krožijo. Ustvarjena datoteka je v obeh primerih ista vrsta predmeta, zato je preverjanje v tem, ali oba konca hranita enake bajte, ne pa v tem, kateri zapis jih je ustvaril.
Ne zamenjujte tls-auth s tls-crypt. Oba varujeta krmilni kanal, vendar tls-crypt ga tudi šifrira in skrije rokovanje pred opazovalci, in nadomesti delitev smeri z lastno obdelavo ključev. Profil z enim ne bo sodeloval z nasprotnikom, nastavljenim za drugega, in nobeno uglaševanje digesta ne zapre te vrzeli.
Oznako reproducirajte samo iz resnične oblike
Reprodukcija, natančna na bajt, je ločena naloga od poganjanja VPN in deluje le z resničnimi vhodi: izvedbo in različico, ki sta zgradili paket, izbranim digestom, smerjo in dejanskimi bajti, vključno z identifikatorjem seje in poljem potrditev. Besedilni prikaz seznama polj niso ti bajti.
Dolžina oznake izhaja iz digesta, zato se predpostavka o fiksni dolžini zlomi v trenutku, ko jo nekdo spremeni. Zgoščujte paket tako, kot to počne izvedba, ne tako, kot ga predstavlja tabela v blogu, in primerjajte s posnetkom, vzetim pri istem nasprotniku, ne pa s pričakovanjem, izpeljanim ročno.
To vajo držite stran od produkcijskih profilov. Nič pri reprodukciji oznake ne pove, ali naj namestitev vklopi zaščito.
Razveljavite neskladje, ne da bi odstranili zaščito
Mamljiv preizkus je izbrisati tls-auth, videti, da je povezava uspešna, in sklepati, da je bil ključ napačen. Tak odgovor vas stane zaščite in ne nauči ničesar o tem, katera od treh vrednosti se ni ujemala. Namesto tega pridobite odobreno ujemajočo se konfiguracijo s strani strežnika in primerjajte z njo.
Pripravite spremembo tako, da bo razveljavljiva. Shranite prejšnjo konfiguracijo strežnika in ključno datoteko, uporabite popravljeni par, preverite, da odjemalec dokonča rokovanje, in šele nato odstranite varnostno kopijo. Če odjemalci po spremembi odpovejo, obnovite prejšnje datoteke, namesto da med izpadom improvizirate tretjo različico. Obnovitev naj bo en ukaz, ki ga že poznate, preden začnete.
Na koncu se spomnite, kaj pomeni uspešno preverjanje. Dokazuje, da ima nasprotnik skupni ključ, ne pa da je njegovo potrdilo ali račun pooblaščen, in ne pove ničesar o dogovorjenem šifriranju podatkovnega kanala. Pooblastitev in zaščita podatkov se vzpostavita pozneje, zato je čisto preverjanje ovojnice izhodišče in ne sodba.