Kan et RSA-certifikat fungere med dh none i OpenVPN?

Her er en serverkonfiguration, der siger dh none ved siden af et certifikat, der siger RSA, plus en nagende mistanke om, at en af dem må være forkert. Intet er forkert. Certifikatet signerer og autentificerer; nøgleudvekslingen etablerer en fælles hemmelighed. Det er to forskellige opgaver i samme håndtryk, og TLS lader et RSA-certifikat autentificere et håndtryk, der bruger efemær elliptisk-kurve-aftale.

Forvirringen kommer normalt med en migreringsvejledning. Den siger, at DH-parameterfilen skal erstattes med dh none, læseren bemærker, at certifikatet ikke er et elliptisk-kurve-certifikat, og de to fakta behandles som en modsætning.

Hvorfor de to indstillinger ser beslægtede ud

OpenVPNs ældre konfiguration krævede en DH-parameterfil, fordi endelig-felt Diffie-Hellman har brug for domæneparametre, som begge parter er enige om. dh-direktivet pegede på den fil. Når en udrulning skifter til ECDH, kommer parametrene i stedet fra en navngivet kurve, og filen er ikke længere nødvendig, hvilket er det, dh none udtrykker.

Certifikater er en separat akse. De bærer en offentlig nøgle og en signatur, der beviser serverens identitet, og den nøgle kan være RSA eller elliptisk kurve, uanset hvordan sessionsnøglen aftales. Et håndtryk, der bruger ECDHE til nøgleaftale og RSA til autentificering, er almindeligt og bredt udrullet.

Navngivningen gør overlapningen værre. Elliptisk kurve optræder i både ECDHE- og ECDSA-suitenavne, så det er let at antage, at enhver forbindelse, der nævner en kurve, må involvere et kurvecertifikat. Det gør den ikke.

Sådan læses et TLS 1.2-suitenavn korrekt

Tag ECDHE-RSA-AES256-GCM-SHA384. Det første token er nøgleudvekslingsfamilien: efemær elliptisk-kurve Diffie-Hellman. Det andet er autentificeringsfamilien: RSA. Resten beskriver postbeskyttelse og den hash, der bruges i håndtrykket.

En ECDHE-ECDSA-suite bruger samme nøgleudvekslingsfamilie med en anden autentificeringsmetode, så den kræver et elliptisk-kurve-certifikat. En DHE-RSA-suite bruger efemær endelig-felt Diffie-Hellman med RSA-autentificering, og den har faktisk brug for DH-parametre.

Læs et suitenavn fra venstre mod højre og tildel hver del dens opgave. Når tokens er adskilt, ændres spørgsmålet fra »passer mit certifikat til dh none« til »tillader min server en suite, hvis nøgleudveksling ikke kræver en DH-fil«.

Hvad dh none faktisk deaktiverer

dh none fortæller serveren, at den ikke skal indlæse en endelig-felt DH-parameterfil. Det deaktiverer ikke autentificering, certifikatvalidering eller selve TLS. Det kræver til gengæld, at den aftalte nøgleudveksling er en, der ikke har brug for disse parametre, hvilket i praksis betyder en ECDHE-suite eller et TLS 1.3-håndtryk.

Det er det krav, bruddet kommer fra. Hvis serverens TLS-chifferpolitik er begrænset til DHE-suiter, eller hvis en klient kun tilbyder dem, efterlader fjernelsen af parameterfilen ingen brugbar nøgleudvekslingsmetode, og håndtrykket mislykkes. Fejlen vises normalt under kontrolkanalens håndtryk, før nogen brugerautentificering. Læs chifferlisten, før du bebrejder den manglende fil.

På elliptisk-kurve-siden vælges kurven af serverens TLS-konfiguration, og OpenVPN giver en mulighed for at vælge den på ældre grene. TLS 1.3 håndterer gruppeaftalen inde i protokollen og konsulterer slet ikke DH-filen.

dh none er ikke i sig selv en sikkerhedsnedgradering. Styrken af udvekslingen afhænger derefter af den kurve og suite, der faktisk aftales, og derfor er næste skridt at se på, hvad parterne valgte, i stedet for på den fil, der mangler.

Bekræft aftalen før redigering

Skru op for serverens og klientens detaljeringsgrad, og læs den kontrolkanallinje, som OpenVPN udskriver efter en forbindelse. Den angiver TLS-version og den aftalte chiffer og rapporterer modpartens certifikatnøgletype. Den ene linje besvarer det spørgsmål, som konfigurationsfilen kun antyder.

Hvis den viser TLS 1.2 med en ECDHE-RSA-suite og et RSA-certifikat, er kombinationen præcis, hvad dh none forventer, og der er intet at reparere. Hvis den viser en DHE-suite eller et håndtryksfejl uden fælles chiffer, ligger løsningen i chifferpolitikken eller klientens formåen, ikke i certifikatet.

Test den ældste klient, du agter at understøtte, fordi en aktuel klient kan aftale TLS 1.3, mens en ældre er begrænset til TLS 1.2-suiter. Hvis den ældste klient ikke har nogen overlapning, skal du enten udvide de tilladte suiter eller opgradere det endepunkt.

Slå ikke certifikatvalidering fra for at komme forbi en håndtryksfejl. Fejlen fortæller dig, at parterne ikke kunne blive enige om en nøgleudveksling, og deaktiveringen fjerner identitetsgarantien uden at løse aftalen.

Tjekliste: er certifikatet RSA, er en ECDHE-suite tilladt, viser loggen den suite, og aftaler den ældste understøttede klient den også? Hvis alle fire er ja, gør dh none sit arbejde.