Neuspjeh tls-auth obično se prijavljuje kao problem rukovanja, a nikada nije bio. HMAC se provjerava na kontrolnom paketu prije bilo kakve TLS obrade, pa neusklađen ključ ili smjer daje neuspjeh koji izgleda kao problem certifikata i rješava se dva sloja ranije. Tretiranje omotnice kao zasebnog objekta skraćuje dijagnozu: pročitajte polja, potvrdite da se provjera aktivira rano, zatim usporedite tri stvari oko kojih se obje strane moraju složiti.

Čitajte omotnicu redom kojim se gradi

Kontrolni paket nosi identifikator sesije, neobavezni tls-auth HMAC, podatke o ponavljanju i potvrdi te pouzdan identifikator poruke, a nakon toga slijedi sadržaj tipa poruke. Kada je poruka poruka rukovanja, sadržaj je TLS šifrirani tekst. To je cijeli odnos: TLS materijal putuje unutar poruke koju omotnica već štiti. Pogledajte OpenVPN referencu mrežnog protokola koja navodi polja kontrolnog kanala tim redom.

Sloj pouzdanosti lako je zamijeniti s kriptografijom. Potvrde, ponovno slanje i identifikator poruke postoje da bi kontrolne poruke stigle jednom i u redu preko nepouzdanog prijenosa. Oni nisu autentifikacija i ispravan identifikator poruke ništa ne dokazuje o tome tko je poslao paket.

Zadržite ovo grupiranje kao koncept. To nije dijagram redoslijeda bajtova i nije dovoljno za izračun oznake, jer polja koja ulaze u HMAC ovise o implementaciji, verziji i načinu rada.

Pokažite da se provjera aktivira prije rukovanja

Primatelj koji ima zajednički ključ može provjeriti HMAC i odmah odbaciti krivotvoren paket, bez izdvajanja stanja rukovanja ili rada s javnim ključem. Zaštita pokriva i početne pakete rukovanja, zbog čega se pogrešan ključ pojavljuje kao neuspješna veza, a ne kao kasna pogreška autentifikacije.

Povećajte razinu pojedinosti daemona i gledajte kontrolni kanal, a ne uređaj tun:

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

Tražite neuspjeh provjere kontrolnog kanala HMAC prijavljen na razini paketa, prije bilo kakvog TLS upozorenja. TLS upozorenje u zapisu znači da je omotnica prihvaćena i da se neuspjeh preselio prema unutra, što je druga istraga s drugim rješenjem.

Rukovanje smjerom također je ovdje. Kada se statična datoteka ključa koristi s tls-auth, dvije strane zauzimaju suprotne smjerove ključa, a protokol koristi tu podjelu da se uhvaćen paket ne može odraziti natrag pošiljatelju. Obrnut smjer zadržava ključ identičnim i ipak ruši svaki paket. Mijenjajte jednu stranu po jednu, zatim ponovno pokrenite oba daemona da se par učita zajedno.

Uskladite ključ, smjer i digest na obje strane

Tri vrijednosti moraju se slagati i samo jedna od njih je datoteka. Sadržaj statičnog ključa mora biti identičan na obje strane, smjer mora biti suprotan, a digest koji se koristi za HMAC mora se podudarati. Provjerite konfiguraciju prije nego dirnete ključni materijal, jer jedan obrnut smjer objašnjava više neuspjeha od oštećene datoteke:

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

Generirajte zajedničku tajnu alatom, a ne uređivačem, i držite dozvole usko:

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

Starija izdanja prihvaćala su nešto drugačiji redoslijed opcija za generiranje ključa i profili napisani za ta izdanja još kruže. Generirana datoteka ista je vrsta objekta u oba slučaja, pa je provjera u tome drže li obje strane identične bajtove, a ne koja ih je inačica pisanja stvorila.

Ne miješajte tls-auth s tls-crypt. Oba štite kontrolni kanal, ali tls-crypt ga i šifrira te skriva rukovanje od promatrača, i zamjenjuje podjelu smjera vlastitim rukovanjem ključevima. Profil koji koristi jedno neće raditi s partnerom konfiguriranim za drugo, i nikakvo podešavanje digesta ne zatvara taj jaz.

Reproducirajte oznaku samo iz stvarnog formata

Reprodukcija točna do bajta odvojen je zadatak od pokretanja VPN-a i radi samo sa stvarnim ulazima: implementacijom i verzijom koje su izgradile paket, odabranim digestom, smjerom i stvarnim bajtovima uključujući identifikator sesije i niz potvrda. Tekstualni prikaz popisa polja nisu ti bajtovi.

Dužina oznake slijedi iz digesta, pa pretpostavka o fiksnoj dužini pada u trenutku kada je netko promijeni. Heširajte paket kako to čini implementacija, a ne kako ga prikazuje tablica u blog postu, i usporedite sa snimkom uzetim od istog partnera, a ne s očekivanjem koje ste izveli ručno.

Držite tu vježbu dalje od produkcijskih profila. Ništa u reprodukciji oznake ne govori vam treba li implementacija uključiti zaštitu.

Vratite nesklad bez uklanjanja zaštite

Primamljiv test je izbrisati tls-auth, vidjeti da veza uspijeva i zaključiti da je ključ bio pogrešan. Takav odgovor stoji vas zaštite i ne uči ništa o tome koja se od tri vrijednosti razlikovala. Umjesto toga uzmite odobrenu odgovarajuću konfiguraciju sa strane poslužitelja i usporedite s njom.

Pripremite promjenu tako da bude reverzibilna. Sačuvajte prethodnu konfiguraciju poslužitelja i datoteku ključa, primijenite ispravljeni par, provjerite da klijent završi rukovanje i tek onda uklonite sigurnosnu kopiju. Ako klijenti ne uspiju nakon promjene, vratite prethodne datoteke umjesto da improvizirate treću varijantu tijekom prekida. Vraćanje treba biti jedna naredba koju već znate prije nego što počnete.

Na kraju, zapamtite što znači položena provjera. Ona dokazuje da partner ima zajednički ključ, a ne da su njegov certifikat ili račun autorizirani, i ne govori ništa o dogovorenoj šifri kanala podataka. Autorizacija i zaštita podataka uspostavljaju se kasnije, pa je čista provjera omotnice početna točka, a ne presuda.

Povezani članci