Kan eit RSA-sertifikat fungere med dh none i OpenVPN?

Her er ein serverkonfigurasjon som seier dh none ved sida av eit sertifikat som seier RSA, pluss ein gnagande mistanke om at ein av dei må vere feil. Ingenting er feil. Sertifikatet signerer og autentiserer; nøkkelutvekslinga etablerer ei felles hemmelegheit. Det er to ulike jobbar i same handtrykk, og TLS lèt eit RSA-sertifikat autentisere eit handtrykk som brukar efemær elliptisk-kurve-avtale.

Forvirringa kjem vanlegvis med ein migrasjonsrettleiar. Han seier at DH-parameterfila skal bytast ut med dh none, lesaren legg merke til at sertifikatet ikkje er eit elliptisk-kurve-sertifikat, og dei to fakta vert handsama som ei motsetning.

Kvifor dei to innstillingane verkar skylde

Den eldre OpenVPN-konfigurasjonen kravde ei DH-parameterfil fordi endepunkt-felt Diffie-Hellman treng domeneparameter som begge partar er samde om. dh-direktivet peikte på den fila. Når ein utrulling går over til ECDH, kjem parametrane frå ei namngjeven kurve i staden, og fila er ikkje lenger nødvendig, noko dh none uttrykkjer.

Sertifikat er ein separat akse. Dei ber ein offentleg nøkkel og ein signatur som provar identiteten til serveren, og den nøkkelen kan vere RSA eller elliptisk kurve uavhengig av korleis sesjonsnøkkelen vert avtalt. Eit handtrykk som brukar ECDHE til nøkkelavtale og RSA til autentisering, er vanleg og breitt utrulla.

Namngjevinga gjer overlappinga verre. Elliptisk kurve finst i både ECDHE- og ECDSA-suitenamn, så det er lett å anta at kvar tilkopling som nemner ei kurve, må ha eit kurvesertifikat. Det har ho ikkje.

Slik les du eit TLS 1.2-suitenamn rett

Ta ECDHE-RSA-AES256-GCM-SHA384. Det første tokenet er nøkkelutvekslingsfamilien: efemær elliptisk-kurve Diffie-Hellman. Det andre er autentiseringsfamilien: RSA. Resten skildrar postvern og hashen som vert brukt i handtrykket.

Ein ECDHE-ECDSA-suite brukar same nøkkelutvekslingsfamilie med ein annan autentiseringsmetode, så han treng eit elliptisk-kurve-sertifikat. Ein DHE-RSA-suite brukar efemær endepunkt-felt Diffie-Hellman med RSA-autentisering, og den treng faktisk DH-parameter.

Les eit suitenamn frå venstre mot høgre og tildel kvar del jobben sin. Når tokena er skilde, endrar spørsmålet seg frå «passar sertifikatet mitt til dh none» til «tillèt serveren min ein suite der nøkkelutvekslinga ikkje treng ei DH-fil».

Kva dh none faktisk deaktiverer

dh none ber serveren om ikkje å laste inn ei endepunkt-felt DH-parameterfil. Det deaktiverer ikkje autentisering, sertifikatvalidering eller sjølve TLS. Det krev likevel at den avtalte nøkkelutvekslinga ikkje treng desse parametrane, noko som i praksis tyder ein ECDHE-suite eller eit TLS 1.3-handtrykk.

Det er frå dette kravet brotet kjem. Viss TLS-sifferpolitikken til serveren er avgrensa til DHE-suitar, eller ein klient berre tilbyd dei, lèt fjerninga av parameterfila ingen brukbar nøkkelutvekslingsmetode att, og handtrykket mislukkar. Feilen syner seg vanlegvis under handtrykket for kontrollkanalen, før noka brukarautentisering. Les sifferlista før du gjev den manglande fila skulda.

På elliptisk-kurve-sida vert kurva vald av TLS-konfigurasjonen til serveren, og OpenVPN tilbyr eit val for å velje ho på eldre greiner. TLS 1.3 handterer gruppeavtalen inne i protokollen og konsulterer ikkje DH-fila i det heile.

dh none er ikkje i seg sjølv ei sikkerheitsnedgradering. Styrken i utvekslinga avheng då av kurva og suiten som faktisk vert avtalt, og difor er neste steg å sjå på kva partane valde, ikkje på fila som manglar.

Stadfest avtalen før du redigerer

Auk detaljnivået for serveren og klienten, og les kontrollkanallinja som OpenVPN skriv ut etter ei tilkopling. Ho oppgjev TLS-versjonen og den avtalte sifferen, og rapporterer nøkkeltypen til sertifikatet til motparten. Den eine linja svarar på spørsmålet konfigurasjonsfila berre antydar.

Viss ho syner TLS 1.2 med ein ECDHE-RSA-suite og eit RSA-sertifikat, er kombinasjonen nøyaktig det dh none ventar, og det er ingenting å reparere. Viss ho syner ein DHE-suite eller eit handtrykksfeil utan felles siffer, ligg løysinga i sifferpolitikken eller evnene til klienten, ikkje i sertifikatet.

Test den eldste klienten du har tenkt å støtte, fordi ein aktuell klient kan avtale TLS 1.3 medan ein eldre er avgrensa til TLS 1.2-suitar. Viss den eldste klienten ikkje har noka overlapping, utvidar du dei tillatne suitane eller oppgraderer det endepunktet.

Slå ikkje av sertifikatvalidering for å kome forbi eit handtrykksfeil. Feilen fortel deg at partane ikkje klarte å bli samde om ei nøkkelutveksling, og å slå av kontrollen fjernar identitetsgarantien utan å løyse avtalen.

Sjekkliste: er sertifikatet RSA, er ein ECDHE-suite tillaten, syner loggen den suiten, og avtalar den eldste støtta klienten han òg? Viss alle fire er ja, gjer dh none jobben sin.