Dei fleste diskusjonane om OpenVPN-digestar byrjar på feil pakke. Å lese auth SHA256 som «godta berre partar som tilbyr SHA256» er det første ein må avlære. Valet namngir ein digest for bestemte pakkar, og kva pakkar det er, avheng av kanalen og av om den kanalen er AEAD. Arbeid deg gjennom dei fire spørsmåla nedanfor i rekkjefølgje; kvart av dei snevrar inn kva innstillinga kan tyde i utrullinga di.

Namngi kanalen innstillinga skal verne

OpenVPN har ein kontrollkanal som ber TLS-handtrykkstrafikk og ein datakanal som ber nyttelasta i tunnelen. auth-digesten spelar ei rolle i begge, men ikkje den same, og profilen gjer sjeldan skilnaden synleg. Skriv ned kva av dei to du prøver å avgrense før du rører ei konfigurasjonsfil.

Tabellen nedanfor er kortversjonen av korleis det same valet landar i kvar samanheng.

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 reknar med han

Dersom den forhandla datasifra er AES-GCM eller CHACHA20-POLY1305, autentiserer datakanalen seg sjølv, og den separate digesten gjer ikkje arbeidet du kanskje førestiller deg. Begge er AEAD-konstruksjonar, så integritet blir skapt av den same operasjonen som krypterer nyttelasta. Det er ikkje ei nedgradering, men det tyder at ein politikk grunngjeven som «kvar datapakke er HMAC-SHA256» er faktisk feil på den tunnelen. Stadfest den forhandla verdien i serverloggen eller statusutdata frå klienten før du skriv om politikken.

Undersøk sifra som faktisk vart forhandla i staden for lista i profilen, fordi forhandlinga kan lande på eit anna medlem av settet. data-ciphers AES-256-GCM:AES-128-GCM er ei forhandlingsliste, og begge oppføringane er AEAD, så ingen av dei brukar auth-digesten til nyttelastevern.

Behandle vernet av kontrollkanalen som eit eige vedtak

tls-auth legg til ein HMAC på pakkane i kontrollkanalen og tek digesten sin frå auth-innstillinga, og difor kan ein AEAD-tunnel framleis ha ein meiningsfull digest konfigurert. tls-crypt er ei anna ordning med sitt eige faste vern, så ikkje gå ut frå at ho arvar kvar tls-auth-eigenskap. Les dokumentasjonen for mekanismen du valde i staden for å overføre føresetnader mellom dei.

Dei to partane må også bli samde om ordninga og om nøkkelretninga. Ein digest som passar, men ei nøkkelfil brukt i feil retning, gjev eit handtrykk som feilar av grunnar digest-innstillinga ikkje kan forklare.

Hald auth skild frå sifferforhandling og sertifikat

Tre innstillingar blir stadig blanda saman: auth-digesten, lista over datasifrer og signaturalgoritmen til sertifikatet. Å endre den første gjev ikkje ut eit sertifikat på nytt, vel ikkje signeringsdigesten og lagar ikkje ein brukarnamn-passord-metode. Definisjonane av protokollvala i OpenVPN 2.6-kjeldene skildrar kvar i sin eigen seksjon, noko som er ei nyttig påminning om at dei er uavhengige knappar.

Når ein part nektar å kople til etter ei digest-endring, er årsaka vanlegvis eit mistilhøve i ei av dei to andre innstillingane. Les begge endar før du endrar noka av dei.

Skriv ned politikken og samanlikn han med køyrande konfigurasjonar

Ei fråsegn på flåtenivå bør nemne dei tillatne datakanalmodusane og det valde vernet av kontrollkanalen uttrykkeleg, i same setning. Den setninga er testbar; «vi brukar SHA256» er det ikkje. Samanlikn han deretter med effektive server- og klientprofilar i staden for med ein mal i eit repositorium.

Avslutt med å registrere kva kvar tunnel faktisk forhandla og kva mekanisme som autentiserte pakkane hans. Ei synleg auth-linje i ein profil er berre prov på konfigurasjonshensikt, og hensikt er den billegaste delen av kontrollen.

Relaterte artiklar