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 koverte kao zasebnog objekta skraćuje dijagnozu: pročitajte polja, potvrdite da se provjera aktivira rano, zatim uporedite tri stvari oko kojih se obje strane moraju složiti.

Čitajte kovertu redom kojim se gradi

Kontrolni paket nosi identifikator sesije, opcionalni tls-auth HMAC, informacije 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 koverta 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 transporta. 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 redoslijeda 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 provjera aktivira prije rukovanja

Primalac 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 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 neuspjeh provjere kontrolnog kanala HMAC prijavljen na nivou paketa, prije bilo kakvog TLS upozorenja. TLS upozorenje u zapisniku znači da je koverta prihvaćena i da se neuspjeh preselio 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šiljaocu. Obrnut smjer zadržava ključ identičnim i ipak obara svaki paket. Mijenjajte jednu stranu po jednu, zatim ponovo 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 što 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 je ista vrsta objekta u oba slučaja, pa je provjera u tome drže li obje strane identične bajtove, a ne koja ih je pravopisna varijanta stvorila.

Ne miješajte tls-auth s tls-crypt. Oba štite kontrolni kanal, ali tls-crypt ga i šifrira te skriva rukovanje od posmatrač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 liste polja nisu ti bajtovi.

Dužina oznake slijedi iz digesta, pa pretpostavka o fiksnoj dužini pada u trenutku kada je neko promijeni. 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 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 košta 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 serverske strane i uporedite s njom.

Pripremite promjenu tako da bude reverzibilna. Sačuvajte prethodnu konfiguraciju servera 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 tokom prekida. Vraćanje treba biti jedna komanda koju već znate prije nego što počnete.

Na kraju, zapamtite šta 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 koverte početna točka, a ne presuda.

Povezani članci