De fleste diskussioner om OpenVPN-digester starter ved den forkerte pakke. At læse auth SHA256 som “accepter kun peers, der tilbyder SHA256”, er det første, du skal aflære. Tilvalget navngiver en digest for bestemte pakker, og hvilke pakker det er, afhænger af kanalen og af, om den kanal er AEAD. Gå de fire spørgsmål nedenfor igennem i rækkefølge; hvert af dem indsnævrer, hvad indstillingen kan betyde i din udrulning.

Navngiv den kanal, indstillingen skal beskytte

OpenVPN har en kontrolkanal, der bærer TLS-håndtrykstrafik, og en datakanal, der bærer tunnelens nyttelast. auth-digesten spiller en rolle i begge, men ikke den samme, og profilen gør sjældent forskellen synlig. Skriv ned, hvilken af de to du prøver at begrænse, før du rører en konfigurationsfil.

Tabellen nedenfor er den korte version af, hvordan det samme tilvalg lander i hver kontekst.

ContextWhat the auth digest does
Data channel without AEADSelects the HMAC digest that authenticates each data packet
Data channel with AEAD, such as GCMUnused for the data channel; the cipher authenticates its own packets
Control channel protected by tls-authSelects the HMAC digest for that protection, even when data is AEAD

Kontroller, om datakanalen er AEAD, før du regner med den

Hvis den forhandlede dataciffer er AES-GCM eller CHACHA20-POLY1305, autentificerer datakanalen sig selv, og den separate digest udfører ikke det arbejde, du måske forestiller dig. Begge er AEAD-konstruktioner, så integritet skabes af den samme operation, der krypterer nyttelasten. Det er ikke en nedgradering, men det betyder, at en politik begrundet som “hver datapakke er HMAC-SHA256” er faktuelt forkert på den tunnel. Bekræft den forhandlede værdi i serverloggen eller klientens statusoutput, før du omskriver politikken.

Undersøg den ciffer, der faktisk blev forhandlet, i stedet for listen i profilen, fordi forhandlingen kan lande på et andet medlem af sættet. data-ciphers AES-256-GCM:AES-128-GCM er en forhandlingsliste, og begge poster er AEAD, så ingen af dem bruger auth-digesten til nyttelastbeskyttelse.

Behandl beskyttelsen af kontrolkanalen som en selvstændig beslutning

tls-auth tilføjer en HMAC til kontrolkanalens pakker og tager sin digest fra auth-indstillingen, og derfor kan en AEAD-tunnel stadig have en meningsfuld digest konfigureret. tls-crypt er en anden ordning med sin egen faste beskyttelse, så antag ikke, at den arver enhver tls-auth-egenskab. Læs dokumentationen for den mekanisme, du valgte, i stedet for at overføre antagelser mellem dem.

De to peers skal også være enige om ordningen og om nøgleretningen. En digest, der passer, men en nøglefil brugt i den forkerte retning, giver et håndtryk, der fejler af grunde, som digestindstillingen ikke kan forklare.

Hold auth adskilt fra cifferforhandling og certifikater

Tre indstillinger bliver konstant blandet sammen: auth-digesten, listen over datacifre og certifikatets signaturalgoritme. At ændre den første genudsteder ikke et certifikat, vælger ikke dets signeringsdigest og opretter ikke en brugernavn-adgangskode-metode. Protokoltilvalgenes definitioner i OpenVPN 2.6-kilderne beskriver hver i sit eget afsnit, hvilket er en nyttig påmindelse om, at de er uafhængige knapper.

Når en peer nægter at forbinde efter en digestændring, er årsagen normalt en uoverensstemmelse i en af de to andre indstillinger. Læs begge ender, før du ændrer nogen af dem.

Skriv politikken ned, og sammenlign den med kørende konfigurationer

En erklæring på flådeniveau bør nævne de tilladte datakanaltilstande og den valgte kontrolkanalbeskyttelse udtrykkeligt i samme sætning. Den sætning er testbar; “vi bruger SHA256” er ikke. Sammenlign den derefter med effektive server- og klientprofiler i stedet for med en skabelon i et repository.

Afslut med at registrere, hvad hver tunnel faktisk forhandlede, og hvilken mekanisme der autentificerede dens pakker. En synlig auth-linje i en profil er kun bevis på konfigurationshensigt, og hensigt er den billigste del af kontrollen.

Relaterede artikler