DH-fil eller tls-auth-nøgle? At skelne to OpenVPN-filer

To filer, to direktiver og en vane med at navngive begge efter det, de konfigurerer. Sådan ender dh.pem på en tls-auth-linje, og klienten fejler med en besked om et uventet nøgleformat. Beslutningen foran dig er ikke, hvilken fil der er stærkest. Det er, hvilken rolle udrulningen faktisk har brug for, og tre betingelser afgør det: hvilken nøgleudveksling din TLS-stak vil forhandle, om du overhovedet vil have godkendelse af kontrolkanalen, og om materialet skal forblive hemmeligt.

Svar på dem i rækkefølge, og filspørgsmålet besvarer sig selv. Spring dem over, og direktivnavnene begynder at se udskiftelige ud, hvilket netop er den tilstand, fejlen kommer fra.

Læs etiketten før filnavnet

Filens første linje er mere informativ end dens navn, fordi et navn er en menneskelig konvention, og etiketten produceres af værktøjet. Diffie-Hellman-parametre bærer en PEM-etiket BEGIN DH PARAMETERS. En statisk OpenVPN-nøgle er en helt anden struktur med sin egen header og hex-nyttelast.

Omdøbning konverterer intet. En parameterfil kaldet ta.key er stadig parametre, og en statisk nøgle kaldet dh.pem er stadig en statisk nøgle; parseren læser indholdet og afviser uoverensstemmelsen. Kontroller, før du redigerer profilen:

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

Tre betingelser der afgør, hvilken fil du har brug for

Den første betingelse er udvekslingen. Et Diffie-Hellman-håndtryk i et endeligt felt har brug for en gruppe, og dh-direktivet er stedet, hvor serveren navngiver parametrene til den. Et håndtryk på en elliptisk kurve har slet ikke brug for den fil, fordi kurven er parametersættet. Hvis din server kun forhandler ECDHE-suiter, er en DH-fil død vægt frem for ekstra styrke.

Den anden betingelse er godkendelse af kontrolkanalen, en separat funktion med sit eget materiale. En tls-auth-fil er en delt statisk nøgle, som begge parter har, brugt til at signere kontrolkanalpakker, så en ikke-godkendt part ikke engang kan fuldføre håndtrykket. Den findes, uanset om du bruger DH i et endeligt felt, og den har intet at gøre med gruppeparametrene.

Den tredje betingelse er hemmeligholdelse og distribution. DH-parametre må offentliggøres uden at svække sessionen, fordi de hemmelige værdier genereres pr. håndtryk og aldrig forlader parterne. En statisk nøgle må ikke offentliggøres: det er de samme bytes i begge ender, den roterer ikke af sig selv, og enhver, der har den, kan fremstille gyldige signaturer til kontrolkanalen. De to svar peger på helt forskellige håndteringsregler, og derfor kan den ene fil ligge i et repository og den anden ikke.

Generér det rigtige materiale til hver rolle

Brug det værktøj, der producerer det format, direktivet forventer, i stedet for at konvertere mellem dem. Til den delte nøgle på OpenVPN 2.6 angiver generatorens typede form formålet eksplicit.

openvpn --genkey tls-auth ta.key

Den kommando opretter nyt hemmeligt materiale; den reparerer eller inspicerer ikke en eksisterende nøgle, og kører du den igen, får du en anden nøgle, som de andre parter ikke har. Kopiér den resulterende fil til de parter, der har brug for den, gennem en kanal, du ville bruge til enhver delt hemmelighed, og hold retningskonventionen konsistent: med tls-auth bruger den ene side key-direction 0 og den anden key-direction 1.

DH-parametre kommer, når du har brug for dem, fra parametergenerering og ikke fra en nøglegenerator, og deres oprindelse betyder noget, selv om outputtet er offentligt. En gruppe hentet fra en ukendt kilde bliver ikke troværdig af at være offentlig; den skal stadig være en gruppe, som dine parter er enige om, og en, der ikke svækkes af sin størrelse eller konstruktion.

Hvad dh none betyder, og hvad det ikke betyder

dh none er et rigtigt direktiv med en snæver betydning: ingen parameterfil for endelige felter indlæses, fordi håndtrykket bruger Diffie-Hellman på elliptisk kurve. Det er ikke en forkortelse for at »springe DH-trinnet over« i betydningen at svække noget, og det beder bestemt ikke OpenVPN om at acceptere en anden fil som erstatning.

To fejl følger af at læse det forkert. Den første er at antage, at dh none fjerner behovet for tls-auth, mens de to styrer forskellige ting. Den anden er at beholde en forældet dh-linje ved siden af en konfiguration med kun kurve og derefter undre sig over, hvilken fil serveren faktisk bruger; hvis direktivet er der, læses filen, og en brudt sti der får opstarten til at fejle af en grund, der intet har med den udveksling at gøre, som vil blive forhandlet.

Hvis den forkerte fil allerede er udrullet

Gendan den tilsigtede hemmelighed fra profilejeren, og lad certificatverifikationen være i fred, mens du gør det. Fejlen er en formatuoverensstemmelse, ikke en tillidsfejl, og at slå verifikationen fra for at komme forbi fejlen erstatter et opstartsproblem med et lydløst et.

Adskil derefter de to hændelser, som folk har en tendens til at slå sammen. Offentliggørelse af en DH-parameterfil er næsten uskadelig, fordi parametrene var offentlige af design. At eksponere tls-auth-nøglen er en anden begivenhed: nøglen godkender kontrolkanalpakker for enhver part, der har den, så udskiftningen skal koordineres i hele udrulningen i stedet for at blive anvendt på én vært.

Et kontrol på fem minutter afgør, hvilken sag du er i: læs første linje af hver fil, bekræft det direktiv, der henviser til den, og bekræft, at filens distribution svarer til det, materialet kræver. Det er et mindre arbejde end at genskabe en fungerende PKI, og det er det, de tre betingelser hele tiden pegede på.