DH-bestand of tls-auth-sleutel? Twee OpenVPN-bestanden onderscheiden

Twee bestanden, twee richtlijnen en de gewoonte om beide te noemen naar wat ze configureren. Zo belandt een dh.pem op een tls-auth-regel en faalt de client met een melding over een onverwacht sleutelformaat. De beslissing voor je ligt niet in welk bestand sterker is. Het gaat erom welke rol de uitrol echt nodig heeft, en drie voorwaarden beslechten dat: welke sleuteluitwisseling je TLS-stack gaat onderhandelen, of je überhaupt authenticatie van het controlekanaal wilt, en of het materiaal geheim moet blijven.

Beantwoord ze in volgorde en de bestandsvraag beantwoordt zichzelf. Sla ze over en de richtlijnnamen gaan eruitzien als uitwisselbaar, en dat is precies de toestand waar de fout vandaan komt.

Lees het label voor de bestandsnaam

De eerste regel van het bestand zegt meer dan de naam, want een naam is een menselijke conventie en het label wordt door het gereedschap gemaakt. Diffie-Hellman-parameters dragen een PEM-label BEGIN DH PARAMETERS. Een statische OpenVPN-sleutel is een heel andere structuur, met een eigen kop en hex-payload.

Hernoemen converteert niets. Een parameterbestand met de naam ta.key is nog steeds parameters, en een statische sleutel met de naam dh.pem is nog steeds een statische sleutel; de parser leest de inhoud en weigert de mismatch. Controleer voordat je het profiel bewerkt:

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

Drie voorwaarden die bepalen welk bestand je nodig hebt

De eerste voorwaarde is de uitwisseling. Een Diffie-Hellman-handshake in een eindig veld heeft een groep nodig, en de richtlijn dh is waar de server de parameters daarvoor benoemt. Een handshake op een elliptische curve heeft dat bestand helemaal niet nodig, omdat de curve de parameterset is. Als je server alleen ECDHE-suites onderhandelt, is een DH-bestand dood gewicht in plaats van extra sterkte.

De tweede voorwaarde is authenticatie van het controlekanaal, een aparte functie met eigen materiaal. Een tls-auth-bestand is een gedeelde statische sleutel die beide peers hebben, gebruikt om pakketten van het controlekanaal te ondertekenen zodat een niet-geauthenticeerde peer de handshake niet eens kan afronden. Het bestaat ongeacht of je DH in een eindig veld gebruikt, en het heeft niets met de groepparameters te maken.

De derde voorwaarde is geheimhouding en distributie. DH-parameters mogen worden gepubliceerd zonder de sessie te verzwakken, omdat de geheime waarden per handshake worden gegenereerd en de peers nooit verlaten. Een statische sleutel mag niet worden gepubliceerd: het zijn dezelfde bytes aan beide uiteinden, hij roteert niet vanzelf, en iedereen die hem heeft kan geldige handtekeningen voor het controlekanaal produceren. Die twee antwoorden wijzen op volledig verschillende omgangsregels, en daarom kan het ene bestand in een repository staan en het andere niet.

Genereer het juiste materiaal voor elke rol

Gebruik het gereedschap dat het formaat produceert dat de richtlijn verwacht, in plaats van tussen beide te converteren. Voor de gedeelde sleutel op OpenVPN 2.6 noemt de getypeerde vorm van de generator het doel expliciet.

openvpn --genkey tls-auth ta.key

Dat commando maakt nieuw geheim materiaal; het repareert of inspecteert geen bestaande sleutel, en opnieuw uitvoeren geeft je een andere sleutel die de andere peers niet hebben. Kopieer het resulterende bestand naar de peers die het nodig hebben via een kanaal dat je voor elk gedeeld geheim zou gebruiken, en houd de richtingsconventie consistent: met tls-auth gebruikt de ene kant key-direction 0 en de andere key-direction 1.

DH-parameters komen, wanneer je ze nodig hebt, uit parametergeneratie en niet uit een sleutelgenerator, en hun herkomst is belangrijk ook al is de uitvoer openbaar. Een groep uit een onbekende bron wordt niet betrouwbaar door openbaar te zijn; het moet nog steeds een groep zijn waarover je peers het eens zijn en een die niet door zijn grootte of constructie wordt verzwakt.

Wat dh none doet en wat niet

dh none is een echte richtlijn met een smalle betekenis: er wordt geen parameterbestand voor een eindig veld geladen, omdat de handshake Diffie-Hellman op een elliptische curve gebruikt. Het is geen afkorting voor ‘sla de DH-stap over’ in de zin van iets verzwakken, en het zegt OpenVPN zeker niet dat het een ander bestand als vervanging moet accepteren.

Twee fouten volgen uit verkeerd lezen. De eerste is aannemen dat dh none de behoefte aan tls-auth opheft, terwijl de twee verschillende dingen besturen. De tweede is een verouderde dh-regel naast een configuratie met alleen een curve houden en je dan afvragen welk bestand de server werkelijk gebruikt; als de richtlijn aanwezig is, wordt het bestand gelezen, en een gebroken pad daar laat het opstarten mislukken om een reden die niets met de uit te onderhandelen uitwisseling te maken heeft.

Als het verkeerde bestand al is uitgerold

Herstel het bedoelde geheim bij de profieleigenaar en laat certificaatverificatie met rust terwijl je dat doet. De fout is een formaatverschil, geen vertrouwensfout, en verificatie uitschakelen om de fout te omzeilen vervangt een opstartprobleem door een stil probleem.

Scheid daarna de twee incidenten die mensen geneigd zijn samen te voegen. Een DH-parameterbestand publiceren is vrijwel onschadelijk, omdat de parameters ontwerpmatig openbaar waren. De tls-auth-sleutel blootleggen is een andere gebeurtenis: de sleutel authenticeert pakketten van het controlekanaal voor elke peer die hem heeft, dus vervanging moet over de hele uitrol worden gecoördineerd in plaats van op één host toegepast.

Een controle van vijf minuten beslist in welk geval je zit: lees de eerste regel van elk bestand, bevestig de richtlijn die ernaar verwijst en bevestig dat de distributie van het bestand past bij wat het materiaal vereist. Dat is minder werk dan een werkende PKI opnieuw genereren, en dat is waar de drie voorwaarden al die tijd op wezen.