Sporing av OpenVPN-kontrollpakkar: tls-auth før TLS

Ein tls-auth-feil vert vanlegvis rapportert som eit handtrykksproblem, og det har han aldri vore. HMAC-en vert kontrollert på kontrollpakken før noka TLS-behandling skjer, så ein feil nøkkel eller retning gir ein feil som ser ut som eit sertifikatproblem og vert avgjort to lag tidlegare. Om ein behandlar konvolutten som sitt eige objekt, vert diagnosen kort: les felta, stadfest at kontrollen slår til tidleg, og samanlikn deretter dei tre tinga begge endar må vere samde om.

Les konvolutten i den rekkjefølgja han vert bygd

Ein kontrollpakke ber ein sesjonsidentifikator, den valfrie tls-auth-HMAC-en, replay- og kvitteringsinformasjon og ein påliteleg meldingsidentifikator, og deretter følgjer nyttelasta for meldingstypen. Når meldinga er ei handtrykksmelding, er nyttelasta tilfeldigvis TLS-chiffertekst. Det er heile tilhøvet: TLS-materiale reiser inne i ei melding som konvolutten allereie vernar. OpenVPN-referansen for nettverksprotokollen listar opp felta i kontrollkanalen i den rekkjefølgja.

Pålitelegheitslaget vert lett forveksla med kryptografi. Kvitteringar, vidaresending og meldingsidentifikatoren finst for at kontrollmeldingar skal kome fram éin gong og i rett rekkjefølgje over ein upåliteleg transport. Dei er ikkje autentisering, og ein korrekt meldingsidentifikator bevisar ingenting om kven som sende pakken.

Hald denne grupperinga konseptuell. Det er ikkje eit byte-rekkjefølgjediagram, og det er ikkje nok til å rekne ut ein tag, fordi felta som går inn i HMAC-en er avhengige av implementasjon, versjon og modus.

Vis at kontrollen slår til før handtrykket

Ein mottakar med den delte nøkkelen kan verifisere HMAC-en og kaste ein forfalska pakke med ein gong, utan å tildele handtrykkstilstand eller gjere offentleg-nøkkel-arbeid. Vernet dekkjer også dei første handtrykkspakkane, og nettopp difor viser ein feil nøkkel seg som ei mislukka tilkopling i staden for som ein sein autentiseringsfeil.

Skru opp detaljnivået for daemonen og følg med på kontrollkanalen i staden for tun-eininga:

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

Det du leitar etter, er ein HMAC-verifiseringsfeil i kontrollkanalen rapportert på pakkenivå, før noka TLS-åtvaring. Ei TLS-åtvaring i loggen tyder på at konvolutten vart godteken og feilen flytta innover, noko som er ei anna undersøking med ei anna løysing.

Retningshandtering høyrer også heime her. Når ei statisk nøkkelfil vert brukt med tls-auth, tek dei to endane motsette nøkkelretningar, og protokollen brukar denne delinga slik at ein fanga pakke ikkje kan reflekterast tilbake til avsendararen. Å snu retninga held nøkkelen identisk og får likevel kvar pakke til å feile. Endre éin ende om gongen, og start deretter båe daemonane på nytt slik at paret vert lasta saman.

Avstem nøkkel, retning og digest i båe endar

Tre verdiar må stemme, og berre éin av dei er fila. Innhaldet i den statiske nøkkelen må vere identisk i båe endar, retninga må vere motsett, og digesten som vert brukt til HMAC-en, må stemme. Kontroller konfigurasjonen før du rører nøkkelmaterialet, fordi éi omvend retning forklarar fleire feil enn ei skadd fil:

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

Generer den delte løyndomen med verktøyet i staden for med ein editor, og hald rettane stramme:

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

Eldre utgåver godtok ei litt anna valrekkjefølgje for nøkkelgenerering, og profilar skrivne for desse utgåvene sirkulerer framleis. Den genererte fila er same type objekt i båe tilfelle, så kontrollen er om båe endar har identiske byte, ikkje kva stavemåte som skapte dei.

Ikkje forveksle tls-auth med tls-crypt. Båe vernar kontrollkanalen, men tls-crypt krypterer han også og skjuler handtrykket for observatørar, og det erstattar retningsdelinga med si eiga nøkkelhandtering. Ein profil med den eine vil ikkje samarbeide med ein motpart konfigurert for den andre, og inga digest-justering lukkar det gapet.

Gjenskap ein tag berre frå det verkelege formatet

Byte-nøyaktig gjenskaping er ei anna oppgåve enn å køyre ein VPN, og ho verkar berre med dei verkelege inndataa: implementasjonen og versjonen som bygde pakken, den valde digesten, retninga og dei faktiske byta, inkludert sesjonsidentifikator og kvitteringsarray. Ei tekstleg framstilling av feltlista er ikkje desse byta.

Taglengda følgjer av digesten, så ein føresetnad om fast lengd bryt saman i det augneblunken nokon endrar henne. Hash pakken slik implementasjonen gjer, ikkje slik ein tabell i eit blogginnlegg framstiller det, og samanlikn med eit opptak frå same motpart i staden for med ei forventning du har leidd ut for hand.

Hald den øvinga borte frå produksjonsprofilar. Ingenting ved å gjenskape ein tag fortel deg om ein utrulling bør slå på vernet.

Rull tilbake ein usemje utan å fjerne vernet

Den freistande testen er å slette tls-auth, sjå at tilkoplinga lukkast og konkludere med at nøkkelen var feil. Det svaret kostar deg vernet og lærer deg ingenting om kva av dei tre verdiane som var usamd. Hent i staden den godkjende samsvarande konfigurasjonen frå serversida og samanlikn med han.

Førebu endringa slik at ho kan rullast tilbake. Ta vare på førre serverkonfigurasjon og nøkkelfil, bruk det korrigerte paret, stadfest at ein klient fullfører handtrykket, og fjern først deretter tryggleikskopien. Om klientar feilar etter endringa, gjenopprett dei førre filene i staden for å improvisere ein tredje variant under ein driftsforstyrring. Gjenopprettinga bør vere éin kommando du allereie kjenner før du byrjar.

Til slutt, hugs kva ein bestått kontroll tyder. Han bevisar at motparten har den delte nøkkelen, ikkje at sertifikatet eller kontoen er autorisert, og han seier ingenting om den forhandla chifferen for datakanalen. Autorisasjon og datatryggleik vert etablert seinare, så ein rein konvoluttkontroll er eit utgangspunkt og ikkje ein dom.