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

En tls-auth-feil rapporteres vanligvis som et håndtrykksproblem, og det har den aldri vært. HMAC-en kontrolleres på kontrollpakken før noen TLS-behandling skjer, så en feil nøkkel eller retning gir en feil som ser ut som et sertifikatproblem og avgjøres to lag tidligere. Behandles konvolutten som sitt eget objekt, blir diagnosen kort: les feltene, bekreft at kontrollen slår til tidlig, og sammenlign deretter de tre tingene begge ender må være enige om.

Les konvolutten i den rekkefølgen den bygges

En kontrollpakke bærer en sesjonsidentifikator, den valgfrie tls-auth-HMAC-en, replay- og kvitteringsinformasjon og en pålitelig meldingsidentifikator, og deretter følger nyttelasten for meldingstypen. Når meldingen er en håndtrykksmelding, er nyttelasten tilfeldigvis TLS-chiffertekst. Det er hele forholdet: TLS-materiale reiser inne i en melding som konvolutten allerede beskytter. OpenVPN-referansen for nettverksprotokollen lister opp feltene i kontrollkanalen i den rekkefølgen.

Pålitelighetslaget forveksles lett med kryptografi. Kvitteringer, videresending og meldingsidentifikatoren finnes for at kontrollmeldinger skal ankomme én gang og i riktig rekkefølge over en upålitelig transport. De er ikke autentisering, og en korrekt meldingsidentifikator beviser ingenting om hvem som sendte pakken.

Hold denne grupperingen konseptuell. Det er ikke et byte-rekkefølgediagram, og det er ikke nok til å beregne en tag, fordi feltene som inngår i HMAC-en avhenger av implementasjon, versjon og modus.

Vis at kontrollen slår til før håndtrykket

En mottaker med den delte nøkkelen kan verifisere HMAC-en og forkaste en forfalsket pakke umiddelbart, uten å tildele håndtrykkstilstand eller utføre offentlig-nøkkel-arbeid. Beskyttelsen dekker også de første håndtrykkspakkene, og nettopp derfor viser en feil nøkkel seg som en mislykket tilkobling i stedet for som en sen autentiseringsfeil.

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

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

Det du leter etter, er en HMAC-verifiseringsfeil i kontrollkanalen rapportert på pakkenivå, før noen TLS-advarsel. En TLS-advarsel i loggen betyr at konvolutten ble godtatt og feilen flyttet innover, noe som er en annen undersøkelse med en annen løsning.

Retningshåndtering hører også hjemme her. Når en statisk nøkkelfil brukes med tls-auth, tar de to endene motsatte nøkkelretninger, og protokollen bruker denne delingen slik at en fanget pakke ikke kan reflekteres tilbake til avsenderen. Å snu retningen holder nøkkelen identisk og får likevel hver pakke til å feile. Endre én ende om gangen, og start deretter begge daemonene på nytt slik at paret lastes sammen.

Avstem nøkkel, retning og digest i begge ender

Tre verdier må stemme, og bare én av dem er filen. Innholdet i den statiske nøkkelen må være identisk i begge ender, retningen må være motsatt, og digesten som brukes til HMAC-en, må stemme. Kontroller konfigurasjonen før du rører nøkkelmaterialet, fordi én enkelt omvendt retning forklarer flere feil enn en skadet fil:

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

Generer den delte hemmeligheten med verktøyet i stedet for med en editor, og hold rettighetene stramme:

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

Eldre utgivelser godtok en litt annen valgrekkefølge for nøkkelgenerering, og profiler skrevet for disse utgivelsene sirkulerer fortsatt. Den genererte filen er samme type objekt i begge tilfeller, så kontrollen er om begge ender har identiske byte, ikke hvilken stavemåte som skapte dem.

Ikke forveksle tls-auth med tls-crypt. Begge beskytter kontrollkanalen, men tls-crypt krypterer den også og skjuler håndtrykket for observatører, og det erstatter retningsdelingen med sin egen nøkkelhåndtering. En profil med den ene vil ikke samarbeide med en motpart konfigurert for den andre, og ingen digest-justering lukker det gapet.

Gjenskap en tag bare fra det virkelige formatet

Byte-nøyaktig gjenskapning er en annen oppgave enn å kjøre en VPN, og den virker bare med de virkelige inndataene: implementasjonen og versjonen som bygde pakken, den valgte digesten, retningen og de faktiske bytene, inkludert sesjonsidentifikator og kvitteringsarray. En tekstlig fremstilling av feltlisten er ikke disse bytene.

Taglengden følger av digesten, så en antakelse om fast lengde bryter sammen i det øyeblikket noen endrer den. Hash pakken slik implementasjonen gjør, ikke slik en tabell i et blogginnlegg fremstiller det, og sammenlign med et opptak fra samme motpart i stedet for med en forventning du har utledet for hånd.

Hold den øvelsen borte fra produksjonsprofiler. Ingenting ved å gjenskape en tag forteller deg om en utrulling bør slå på beskyttelsen.

Rull tilbake en uoverensstemmelse uten å fjerne beskyttelsen

Den fristende testen er å slette tls-auth, se at tilkoblingen lykkes og konkludere med at nøkkelen var feil. Det svaret koster deg beskyttelsen og lærer deg ingenting om hvilken av de tre verdiene som var uenig. Hent i stedet den godkjente samsvarende konfigurasjonen fra serversiden og sammenlign med den.

Forbered endringen slik at den kan rulles tilbake. Ta vare på forrige serverkonfigurasjon og nøkkelfil, bruk det korrigerte paret, bekreft at en klient fullfører håndtrykket, og fjern først deretter sikkerhetskopien. Hvis klienter feiler etter endringen, gjenopprett de forrige filene i stedet for å improvisere en tredje variant under en driftsforstyrrelse. Gjenopprettingen bør være én kommando du allerede kjenner før du begynner.

Til slutt, husk hva en bestått kontroll betyr. Den beviser at motparten har den delte nøkkelen, ikke at sertifikatet eller kontoen er autorisert, og den sier ingenting om den forhandlede chifferen for datakanalen. Autorisasjon og databeskyttelse etableres senere, så en ren konvoluttkontroll er et utgangspunkt og ikke en dom.