De fleste diskusjoner om OpenVPN-digester starter ved feil pakke. Å lese auth SHA256 som «godta bare parter som tilbyr SHA256» er det første en må avlære. Valget navngir en digest for bestemte pakker, og hvilke pakker det er avhenger av kanalen og av om den kanalen er AEAD. Arbeid deg gjennom de fire spørsmålene nedenfor i rekkefølge; hvert av dem snevrer inn hva innstillingen kan bety i din utrulling.

Navngi kanalen innstillingen skal beskytte

OpenVPN har en kontrollkanal som bærer TLS-håndtrykkstrafikk og en datakanal som bærer tunnelens nyttelast. auth-digesten spiller en rolle i begge, men ikke den samme, og profilen gjør sjelden forskjellen synlig. Skriv ned hvilken av de to du prøver å begrense før du rører en konfigurasjonsfil.

Tabellen nedenfor er kortversjonen av hvordan det samme valget 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 datasifferen er AES-GCM eller CHACHA20-POLY1305, autentiserer datakanalen seg selv, og den separate digesten gjør ikke arbeidet du kanskje forestiller deg. Begge er AEAD-konstruksjoner, så integritet skapes av den samme operasjonen som krypterer nyttelasten. Det er ikke en nedgradering, men det betyr at en policy begrunnet som «hver datapakke er HMAC-SHA256» er faktisk feil på den tunnelen. Bekreft den forhandlede verdien i serverloggen eller klientens statusutdata før du skriver om policyen.

Undersøk sifferen som faktisk ble forhandlet i stedet for listen i profilen, fordi forhandlingen kan lande på et annet medlem av settet. data-ciphers AES-256-GCM:AES-128-GCM er en forhandlingsliste, og begge oppføringene er AEAD, så ingen av dem bruker auth-digesten til nyttelastbeskyttelse.

Behandle beskyttelsen av kontrollkanalen som en egen beslutning

tls-auth legger til en HMAC på kontrollkanalens pakker og tar digesten sin fra auth-innstillingen, og derfor kan en AEAD-tunnel fortsatt ha en meningsfull digest konfigurert. tls-crypt er en annen ordning med sin egen faste beskyttelse, så ikke anta at den arver hver tls-auth-egenskap. Les dokumentasjonen for mekanismen du valgte i stedet for å overføre antakelser mellom dem.

De to partene må også bli enige om ordningen og om nøkkelretningen. En digest som passer, men en nøkkelfil brukt i feil retning, gir et håndtrykk som feiler av grunner digest-innstillingen ikke kan forklare.

Hold auth atskilt fra sifferforhandling og sertifikater

Tre innstillinger blir stadig blandet sammen: auth-digesten, listen over datasifre og sertifikatets signaturalgoritme. Å endre den første utsteder ikke et sertifikat på nytt, velger ikke dets signeringsdigest og oppretter ikke en brukernavn-passord-metode. Protokollvalgets definisjoner i OpenVPN 2.6-kildene beskriver hver i sin egen seksjon, noe som er en nyttig påminnelse om at de er uavhengige knapper.

Når en part nekter å koble til etter en digest-endring, er årsaken vanligvis en uoverensstemmelse i en av de to andre innstillingene. Les begge ender før du endrer noen av dem.

Skriv ned policyen og sammenlign den med kjørende konfigurasjoner

En uttalelse på flåtenivå bør nevne de tillatte datakanalmodusene og den valgte kontrollkanalbeskyttelsen eksplisitt, i samme setning. Den setningen er testbar; «vi bruker SHA256» er det ikke. Sammenlign den deretter med effektive server- og klientprofiler i stedet for med en mal i et repositorium.

Avslutt med å registrere hva hver tunnel faktisk forhandlet og hvilken mekanisme som autentiserte pakkene dens. En synlig auth-linje i en profil er bare bevis på konfigurasjonshensikt, og hensikt er den billigste delen av kontrollen.

Relaterte artikler