Vilka OpenVPN-paket skyddar auth-digesten?
Alternativet auth täcker mindre än en profil antyder. Gå igenom kanalen, AEAD-fallet och skyddet av kontrollkanalen innan du sätter en digestpolicy.
De flesta diskussioner om OpenVPN-digester börjar vid fel paket. Att läsa auth SHA256 som ”acceptera bara parter som erbjuder SHA256” är det första man måste avlära sig. Alternativet namnger en digest för vissa paket, och vilka paket det är beror på kanalen och på om den kanalen är AEAD. Arbeta igenom de fyra frågorna nedan i ordning; var och en begränsar vad inställningen kan betyda i din utrullning.
Namnge kanalen som inställningen ska skydda
OpenVPN har en kontrollkanal som bär TLS-handskakningstrafik och en datakanal som bär tunnelns nyttolast. auth-digesten spelar en roll i båda, men inte samma, och profilen gör sällan skillnaden synlig. Skriv ned vilken av de två du försöker begränsa innan du rör en konfigurationsfil.
Tabellen nedan är kortversionen av hur samma alternativ landar i varje sammanhang.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Kontrollera om datakanalen är AEAD innan du förlitar dig på den
Om den förhandlade datasiffran är AES-GCM eller CHACHA20-POLY1305 autentiserar datakanalen sig själv, och den separata digesten utför inte det arbete du kanske föreställer dig. Båda är AEAD-konstruktioner, så integritet skapas av samma operation som krypterar nyttolasten. Det är ingen nedgradering, men det betyder att en policy som motiveras som ”varje datapaket är HMAC-SHA256” är sakligt felaktig på den tunneln. Bekräfta det förhandlade värdet i serverloggen eller klientens statusutdata innan du skriver om policyn.
Undersök siffran som faktiskt förhandlades fram i stället för listan i profilen, eftersom förhandlingen kan landa på en annan medlem av mängden. data-ciphers AES-256-GCM:AES-128-GCM är en förhandlingslista, och båda posterna är AEAD, så ingen av dem förbrukar auth-digesten för nyttolastskydd.
Behandla skyddet av kontrollkanalen som ett eget beslut
tls-auth lägger till en HMAC på kontrollkanalens paket och tar sin digest från auth-inställningen, vilket är varför en AEAD-tunnel fortfarande kan ha en meningsfull digest konfigurerad. tls-crypt är ett annat arrangemang med sitt eget fasta skydd, så utgå inte från att det ärver varje tls-auth-egenskap. Läs dokumentationen för den mekanism du valde i stället för att flytta antaganden mellan dem.
De två parterna måste också komma överens om arrangemanget och om nyckelriktningen. En digest som stämmer men en nyckelfil som används i fel riktning ger en handskakning som misslyckas av skäl som digestinställningen inte kan förklara.
Håll auth åtskilt från sifferförhandling och certifikat
Tre inställningar blandas ständigt ihop: auth-digesten, listan över datasiffror och certifikatets signaturalgoritm. Att ändra den första utfärdar inte ett certifikat på nytt, väljer inte dess signeringsdigest och skapar inte en användarnamn-lösenordsmetod. Protokollalternativens definitioner i OpenVPN 2.6-källorna beskriver var och en i sitt eget avsnitt, vilket är en nyttig påminnelse om att de är oberoende rattar.
När en part vägrar att ansluta efter en digeständring är orsaken vanligtvis en bristande överensstämmelse i en av de två andra inställningarna. Läs båda ändarna innan du ändrar någon av dem.
Skriv ned policyn och jämför den med körande konfigurationer
Ett uttalande på flottnivå bör uttryckligen nämna de tillåtna datakanallägena och det valda skyddet av kontrollkanalen i samma mening. Den meningen är testbar; ”vi använder SHA256” är det inte. Jämför den sedan med effektiva server- och klientprofiler i stället för med en mall i ett arkiv.
Avsluta med att registrera vad varje tunnel faktiskt förhandlade och vilken mekanism som autentiserade dess paket. En synlig auth-rad i en profil är bara bevis på konfigurationsavsikt, och avsikt är den billigaste delen av kontrollen.