DH-fil eller tls-auth-nyckel? Skilja två OpenVPN-filer åt

Två filer, två direktiv och vanan att namnge båda efter det de konfigurerar. Så hamnar en dh.pem på en tls-auth-rad och klienten misslyckas med ett meddelande om ett oväntat nyckelformat. Beslutet framför dig är inte vilken fil som är starkast. Det är vilken roll driftsättningen faktiskt behöver, och tre villkor avgör det: vilket nyckelutbyte din TLS-stack ska förhandla, om du överhuvudtaget vill ha autentisering av kontrollkanalen, och om materialet måste förbli hemligt.

Svara på dem i ordning och filfrågan svarar sig själv. Hoppar du över dem börjar direktivnamnen se utbytbara ut, och det är precis det tillstånd felet kommer från.

Läs etiketten före filnamnet

Första raden i filen säger mer än namnet, eftersom ett namn är en mänsklig konvention och etiketten produceras av verktyget. Diffie-Hellman-parametrar bär en PEM-etikett BEGIN DH PARAMETERS. En statisk OpenVPN-nyckel är en helt annan struktur, med egen header och hexnyttolast.

Att byta namn konverterar ingenting. En parameterfil som heter ta.key är fortfarande parametrar, och en statisk nyckel som heter dh.pem är fortfarande en statisk nyckel; tolken läser innehållet och avvisar missförhållandet. Kontrollera innan du redigerar profilen:

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

Tre villkor som avgör vilken fil du behöver

Det första villkoret är utbytet. En Diffie-Hellman-handskakning i ett ändligt fält behöver en grupp, och direktivet dh är där servern namnger parametrarna för den. En handskakning på elliptisk kurva behöver inte den filen alls, eftersom kurvan är parameteruppsättningen. Om din server bara förhandlar ECDHE-sviter är en DH-fil dödvikt i stället för extra styrka.

Det andra villkoret är autentisering av kontrollkanalen, en separat funktion med eget material. En tls-auth-fil är en delad statisk nyckel som båda parter har, använd för att signera kontrollkanalpaket så att en oautentiserad part inte ens kan slutföra handskakningen. Den finns oavsett om du använder DH i ett ändligt fält, och den har ingenting med grupparametrarna att göra.

Det tredje villkoret är hemlighållande och distribution. DH-parametrar får publiceras utan att försvaga sessionen, eftersom de hemliga värdena genereras per handskakning och aldrig lämnar parterna. En statisk nyckel får inte publiceras: det är samma byte i båda ändar, den roterar inte av sig själv, och den som har den kan producera giltiga signaturer för kontrollkanalen. De två svaren pekar på helt olika hanteringsregler, och därför kan den ena filen ligga i ett arkiv och den andra inte.

Generera rätt material för varje roll

Använd verktyget som producerar det format direktivet förväntar sig i stället för att konvertera mellan dem. För den delade nyckeln på OpenVPN 2.6 anger generatorns typade form syftet uttryckligen.

openvpn --genkey tls-auth ta.key

Det kommandot skapar nytt hemligt material; det reparerar eller inspekterar inte en befintlig nyckel, och kör du det igen får du en annan nyckel som de andra parterna inte har. Kopiera den resulterande filen till de parter som behöver den via en kanal du skulle använda för vilken delad hemlighet som helst, och håll riktningskonventionen konsekvent: med tls-auth använder ena sidan key-direction 0 och den andra key-direction 1.

DH-parametrar kommer, när du behöver dem, från parametergenerering och inte från en nyckelgenerator, och deras ursprung spelar roll även om utdata är offentlig. En grupp hämtad från okänd källa blir inte pålitlig av att vara offentlig; den måste fortfarande vara en grupp som dina parter är överens om och en som inte försvagas av sin storlek eller konstruktion.

Vad dh none betyder och vad det inte betyder

dh none är ett riktigt direktiv med snäv betydelse: ingen parameterfil för ändliga fält laddas, eftersom handskakningen använder Diffie-Hellman på elliptisk kurva. Det är inte en förkortning för ”hoppa över DH-steget” i betydelsen att försvaga något, och det säger absolut inte till OpenVPN att acceptera en annan fil som ersättning.

Två fel följer av att läsa det fel. Det första är att anta att dh none tar bort behovet av tls-auth, medan de två styr olika saker. Det andra är att behålla en inaktuell dh-rad bredvid en konfiguration med bara kurva och sedan undra vilken fil servern faktiskt använder; om direktivet finns läses filen, och en trasig sökväg där får starten att misslyckas av en anledning som inte har med utbytet som ska förhandlas att göra.

Om fel fil redan är driftsatt

Återställ den avsedda hemligheten hos profilägaren och rör inte certifikatverifieringen medan du gör det. Felet är ett formatmissförhållande, inte ett förtroendefel, och att stänga av verifieringen för att komma förbi felet ersätter ett startproblem med ett tyst problem.

Separera sedan de två händelser som människor tenderar att slå ihop. Att publicera en DH-parameterfil är nästan ofarligt, eftersom parametrarna var offentliga av design. Att exponera tls-auth-nyckeln är en annan händelse: nyckeln autentiserar kontrollkanalpaket för varje part som har den, så utbytet måste samordnas över hela driftsättningen i stället för att tillämpas på en enda värd.

En kontroll på fem minuter avgör vilket fall du är i: läs första raden i varje fil, bekräfta direktivet som refererar till den och bekräfta att filens distribution stämmer med vad materialet kräver. Det är mindre arbete än att återskapa en fungerande PKI, och det är vad de tre villkoren pekade på hela tiden.