Neuspeh tls-auth obično se prijavljuje kao problem rukovanja, a nikada nije bio. HMAC se proverava na kontrolnom paketu pre bilo kakve TLS obrade, pa neusklađen ključ ili smer daje neuspeh koji izgleda kao problem sertifikata i rešava se dva sloja ranije. Tretiranje omotnice kao zasebnog objekta skraćuje dijagnozu: pročitajte polja, potvrdite da se provera aktivira rano, zatim uporedite tri stvari oko kojih obe strane moraju da se slože.

Čitajte omotnicu redom kojim se gradi

Kontrolni paket nosi identifikator sesije, opcioni tls-auth HMAC, podatke o ponavljanju i potvrdi, i pouzdan identifikator poruke, a zatim sledi sadržaj tipa poruke. Kada je poruka poruka rukovanja, sadržaj je TLS šifrovani tekst. To je ceo 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 zameniti sa kriptografijom. Potvrde, ponovno slanje i identifikator poruke postoje da bi kontrolne poruke stigle jednom i u redu preko nepouzdanog prenosa. Oni nisu autentifikacija i ispravan identifikator poruke ništa ne dokazuje o tome ko je poslao paket.

Zadržite ovo grupisanje kao koncept. To nije dijagram redosleda bajtova i nije dovoljno za izračunavanje oznake, jer polja koja ulaze u HMAC zavise od implementacije, verzije i režima.

Pokažite da se provera aktivira pre rukovanja

Primalac koji ima zajednički ključ može da proveri HMAC i odmah odbaci krivotvoren paket, bez izdvajanja stanja rukovanja ili rada sa javnim ključem. Zaštita pokriva i početne pakete rukovanja, zbog čega se pogrešan ključ pojavljuje kao neuspešna veza, a ne kao kasna greška autentifikacije.

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

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

Tražite neuspeh provere kontrolnog kanala HMAC prijavljen na nivou paketa, pre bilo kakvog TLS upozorenja. TLS upozorenje u zapisu znači da je omotnica prihvaćena i da se neuspeh preselio prema unutra, što je druga istraga sa drugim rešenjem.

Rukovanje smerom takođe je ovde. Kada se statična datoteka ključa koristi sa tls-auth, dve strane zauzimaju suprotne smerove ključa, a protokol koristi tu podelu da se uhvaćen paket ne može odraziti natrag pošiljaocu. Obrnut smer zadržava ključ identičnim i ipak obara svaki paket. Menjajte jednu stranu po jednu, zatim ponovo pokrenite oba daemona da se par učita zajedno.

Uskladite ključ, smer i digest na obe strane

Tri vrednosti moraju da se slažu i samo jedna od njih je datoteka. Sadržaj statičnog ključa mora biti identičan na obe strane, smer mora biti suprotan, a digest koji se koristi za HMAC mora da se podudara. Proverite konfiguraciju pre nego što dirnete ključni materijal, jer jedan obrnut smer objašnjava više neuspeha od oštećene datoteke:

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

Generišite 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 prihvatala su nešto drugačiji redosled opcija za generisanje ključa i profili napisani za ta izdanja još kruže. Generisana datoteka je ista vrsta objekta u oba slučaja, pa je provera u tome drže li obe strane identične bajtove, a ne koja ih je varijanta pisanja stvorila.

Ne mešajte tls-auth sa tls-crypt. Oba štite kontrolni kanal, ali tls-crypt ga i šifruje te skriva rukovanje od posmatrača, i zamenjuje podelu smerova sopstvenim rukovanjem ključevima. Profil koji koristi jedno neće raditi sa partnerom konfigurisanim za drugo, i nikakvo podešavanje digesta ne zatvara taj jaz.

Reprodukujte oznaku samo iz stvarnog formata

Reprodukcija tač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, smerom i stvarnim bajtovima uključujući identifikator sesije i niz potvrda. Tekstualni prikaz liste polja nisu ti bajtovi.

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

Držite tu vežbu dalje od produkcionih profila. Ništa u reprodukciji oznake ne govori vam treba li implementacija da uključi zaštitu.

Vratite nesklad bez uklanjanja zaštite

Primamljiv test je izbrisati tls-auth, videti da veza uspeva i zaključiti da je ključ bio pogrešan. Takav odgovor košta vas zaštite i ne uči ništa o tome koja se od tri vrednosti razlikovala. Umesto toga uzmite odobrenu odgovarajuću konfiguraciju sa serverske strane i uporedite sa njom.

Pripremite promenu tako da bude reverzibilna. Sačuvajte prethodnu konfiguraciju servera i datoteku ključa, primenite ispravljeni par, proverite da klijent završi rukovanje i tek onda uklonite sigurnosnu kopiju. Ako klijenti ne uspeju nakon promene, vratite prethodne datoteke umesto da improvizujete treću varijantu tokom prekida. Vraćanje treba da bude jedna komanda koju već znate pre nego što počnete.

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

Povezani članci