DH-fil eller tls-auth-nøkkel? Skille to OpenVPN-filer

To filer, to direktiver og en vane med å kalle begge etter det de konfigurerer. Slik ender dh.pem på en tls-auth-linje, og klienten feiler med en melding om et uventet nøkkelformat. Beslutningen foran deg er ikke hvilken fil som er sterkest. Det er hvilken rolle utrullingen faktisk trenger, og tre betingelser avgjør det: hvilken nøkkelutveksling TLS-stakken din vil forhandle, om du i det hele tatt vil ha autentisering av kontrollkanalen, og om materialet må forbli hemmelig.

Svar på dem i rekkefølge, og filspørsmålet besvarer seg selv. Hopper du over dem, begynner direktivnavnene å se utbyttbare ut, og det er nettopp tilstanden feilen kommer fra.

Les etiketten før filnavnet

Første linje i filen er mer informativ enn navnet, fordi et navn er en menneskelig konvensjon og etiketten produseres av verktøyet. Diffie-Hellman-parametere bærer en PEM-etikett BEGIN DH PARAMETERS. En statisk OpenVPN-nøkkel er en helt annen struktur, med sin egen header og hex-nyttelast.

Omdøping konverterer ingenting. En parameterfil som heter ta.key er fortsatt parametere, og en statisk nøkkel som heter dh.pem er fortsatt en statisk nøkkel; parseren leser innholdet og avviser misforholdet. Kontroller før du redigerer profilen:

head -n 1 dh.pem
head -n 1 ta.key

Tre betingelser som avgjør hvilken fil du trenger

Den første betingelsen er utvekslingen. Et Diffie-Hellman-håndtrykk i et endelig felt trenger en gruppe, og dh-direktivet er der serveren navngir parameterne for den. Et håndtrykk på elliptisk kurve trenger ikke den filen i det hele tatt, fordi kurven er parametersettet. Hvis serveren din bare forhandler ECDHE-suiter, er en DH-fil dødvekt i stedet for ekstra styrke.

Den andre betingelsen er autentisering av kontrollkanalen, en egen funksjon med sitt eget materiale. En tls-auth-fil er en delt statisk nøkkel som begge parter har, brukt til å signere kontrollkanalpakker slik at en uautentisert part ikke engang kan fullføre håndtrykket. Den finnes uansett om du bruker DH i et endelig felt, og den har ingenting med gruppeparameterne å gjøre.

Den tredje betingelsen er hemmelighold og distribusjon. DH-parametere kan publiseres uten å svekke sesjonen, fordi de hemmelige verdiene genereres per håndtrykk og aldri forlater partene. En statisk nøkkel må ikke publiseres: det er de samme bytene i begge ender, den roterer ikke av seg selv, og enhver som har den kan produsere gyldige signaturer for kontrollkanalen. De to svarene peker på helt forskjellige håndteringsregler, og derfor kan den ene filen ligge i et depot og den andre ikke.

Generer riktig materiale for hver rolle

Bruk verktøyet som produserer formatet direktivet forventer, i stedet for å konvertere mellom dem. For den delte nøkkelen på OpenVPN 2.6 angir den typede formen til generatoren formålet eksplisitt.

openvpn --genkey tls-auth ta.key

Den kommandoen lager nytt hemmelig materiale; den reparerer eller inspiserer ikke en eksisterende nøkkel, og kjører du den igjen får du en annen nøkkel som de andre partene ikke har. Kopier den resulterende filen til partene som trenger den, gjennom en kanal du ville brukt til enhver delt hemmelighet, og hold retningskonvensjonen konsistent: med tls-auth bruker den ene siden key-direction 0 og den andre key-direction 1.

DH-parametere kommer, når du trenger dem, fra parametergenerering og ikke fra en nøkkelgenerator, og opprinnelsen deres betyr noe selv om utdataene er offentlige. En gruppe hentet fra en ukjent kilde blir ikke pålitelig av å være offentlig; den må fortsatt være en gruppe partene dine er enige om, og en som ikke svekkes av størrelsen eller konstruksjonen.

Hva dh none betyr, og hva det ikke betyr

dh none er et ekte direktiv med en snever betydning: ingen parameterfil for endelige felt lastes, fordi håndtrykket bruker Diffie-Hellman på elliptisk kurve. Det er ikke en forkortelse for «hopp over DH-trinnet» i betydningen å svekke noe, og det ber slett ikke OpenVPN godta en annen fil som erstatning.

To feil følger av å lese det feil. Den første er å anta at dh none fjerner behovet for tls-auth, mens de to styrer forskjellige ting. Den andre er å beholde en utdatert dh-linje ved siden av en konfigurasjon med bare kurve og deretter lure på hvilken fil serveren faktisk bruker; hvis direktivet er der, leses filen, og en brutt sti der får oppstarten til å feile av en grunn som ikke har noe med utvekslingen som skal forhandles å gjøre.

Hvis feil fil allerede er rullet ut

Gjenopprett den tiltenkte hemmeligheten fra profileieren og la sertifikatverifiseringen være i fred mens du gjør det. Feilen er et formatmisforhold, ikke en tillitsfeil, og å slå av verifiseringen for å komme forbi feilen erstatter et oppstartsproblem med et stille et.

Skill deretter de to hendelsene folk har en tendens til å slå sammen. Å publisere en DH-parameterfil er nesten ufarlig, fordi parameterne var offentlige av design. Å eksponere tls-auth-nøkkelen er en annen hendelse: nøkkelen autentiserer kontrollkanalpakker for hver part som har den, så utskiftingen må koordineres i hele utrullingen i stedet for å brukes på én vert.

En kontroll på fem minutter avgjør hvilket tilfelle du er i: les første linje i hver fil, bekreft direktivet som refererer til den, og bekreft at distribusjonen av filen samsvarer med det materialet krever. Det er et mindre arbeid enn å gjenopprette en fungerende PKI, og det er det de tre betingelsene pekte på hele tiden.