Sporing af OpenVPN-kontrolpakker: tls-auth før TLS

En tls-auth-fejl rapporteres normalt som et håndtryksproblem, og det har den aldrig været. HMAC’en kontrolleres på kontrolpakken, før nogen TLS-behandling sker, så en forkert nøgle eller retning giver en fejl, der ligner et certifikatproblem og afgøres to lag tidligere. Behandles konvolutten som sit eget objekt, bliver diagnosen kort: læs felterne, bekræft at kontrollen slår til tidligt, og sammenlign derefter de tre ting, som begge ender skal være enige om.

Læs konvolutten i den rækkefølge, den bygges i

En kontrolpakke bærer en sessionsidentifikator, den valgfrie tls-auth-HMAC, replay- og kvitteringsoplysninger og en pålidelig meddelelsesidentifikator, og derefter følger nyttelasten for meddelelsestypen. Når meddelelsen er en håndtryksmeddelelse, er nyttelasten tilfældigvis TLS-chiffertekst. Det er hele forholdet: TLS-materiale rejser inde i en meddelelse, som konvolutten allerede beskytter. OpenVPN-reference for netværksprotokollen oplister kontrolkanalens felter i den rækkefølge.

Pålidelighedslaget forveksles let med kryptografi. Kvitteringer, genforsendelse og meddelelsesidentifikatoren findes, for at kontrolmeddelelser ankommer én gang og i rækkefølge over en upålidelig transport. De er ikke autentificering, og en korrekt meddelelsesidentifikator beviser intet om, hvem der sendte pakken.

Hold denne gruppering konceptuel. Det er ikke et byte-rækkefølgediagram, og det er ikke nok til at beregne et tag, fordi felterne, der indgår i HMAC’en, afhænger af implementering, version og tilstand.

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

En modtager med den delte nøgle kan verificere HMAC’en og droppe en forfalsket pakke med det samme uden at allokere håndtrykstilstand eller udføre offentlig-nøgle-arbejde. Beskyttelsen dækker også de første håndtrykspakker, og netop derfor viser en forkert nøgle sig som en mislykket forbindelse i stedet for som en sen autentificeringsfejl.

Skru op for daemonens verbositet, og hold øje med kontrolkanalen i stedet for tun-enheden:

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

Det, du leder efter, er en HMAC-verifikationsfejl på kontrolkanalen rapporteret på pakkeniveau, før nogen TLS-advarsel. En TLS-advarsel i loggen betyder, at konvolutten blev accepteret, og at fejlen flyttede indad, hvilket er en anden undersøgelse med en anden løsning.

Retningshåndtering sidder også her. Når en statisk nøglefil bruges med tls-auth, tager de to ender modsatte nøgleretninger, og protokollen bruger den opdeling, så en opfanget pakke ikke kan sendes tilbage til sin afsender. At vende retningen holder nøglen identisk og får stadig hver pakke til at fejle. Skift én ende ad gangen, og genstart derefter begge daemons, så parret indlæses sammen.

Afstem nøgle, retning og digest i begge ender

Tre værdier skal stemme, og kun én af dem er filen. Indholdet af den statiske nøgle skal være identisk i begge ender, retningen skal være modsat, og den digest, der bruges til HMAC’en, skal matche. Kontroller konfigurationen, før du rører nøglematerialet, fordi en enkelt omvendt retning forklarer flere fejl end en beskadiget fil:

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

Generér den delte hemmelighed med værktøjet i stedet for med en editor, og hold rettighederne stramme:

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

Ældre udgivelser accepterede en lidt anden valgrækkefølge til nøglegenerering, og profiler skrevet til de udgivelser cirkulerer stadig. Den genererede fil er den samme slags objekt i begge tilfælde, så kontrollen er, om begge ender har identiske bytes, ikke hvilken stavemåde der skabte dem.

Forveksl ikke tls-auth med tls-crypt. Begge beskytter kontrolkanalen, men tls-crypt krypterer den også og skjuler håndtrykket for iagttagere, og det erstatter retningsopdelingen med sin egen nøglehåndtering. En profil med den ene vil ikke samarbejde med en modpart, der er konfigureret til den anden, og ingen digest-tunig lukker det gab.

Gengiv kun et tag ud fra det rigtige format

Byte-præcis gengivelse er en anden opgave end at køre en VPN, og den virker kun med de rigtige input: implementeringen og versionen, der byggede pakken, den valgte digest, retningen og de faktiske bytes inklusive sessionsidentifikator og kvitteringsarray. En tekstlig gengivelse af feltlisten er ikke de bytes.

Taglængden følger af digesten, så en antagelse om fast længde bryder sammen i det øjeblik, nogen ændrer den. Hash pakken, som implementeringen gør, ikke som en tabel i et blogindlæg fremstiller det, og sammenlign med en optagelse fra samme modpart i stedet for med en forventning, du har udledt i hånden.

Hold den øvelse væk fra produktionsprofiler. Intet ved at gengive et tag fortæller dig, om en udrulning bør aktivere beskyttelsen.

Rul en uoverensstemmelse tilbage uden at fjerne beskyttelsen

Den fristende test er at slette tls-auth, se forbindelsen lykkes og konkludere, at nøglen var forkert. Det svar koster dig beskyttelsen og lærer dig intet om, hvilken af de tre værdier der var uenig. Hent i stedet den godkendte matchende konfiguration fra serversiden, og sammenlign med den.

Forbered ændringen, så den kan rulles tilbage. Behold den tidligere serverkonfiguration og nøglefil, anvend det rettede par, bekræft at en klient fuldfører håndtrykket, og fjern først derefter sikkerhedskopien. Hvis klienter fejler efter ændringen, skal du gendanne de tidligere filer i stedet for at improvisere en tredje variant under et nedbrud. Gendannelsen bør være én kommando, du allerede kender, før du begynder.

Husk til sidst, hvad en bestået kontrol betyder. Den beviser, at modparten har den delte nøgle, ikke at dens certifikat eller konto er autoriseret, og den siger intet om den forhandlede datakanal-chiffer. Autorisation og databeskyttelse etableres senere, så en ren konvolutkontrol er et udgangspunkt og ikke en dom.