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

Her er en serverkonfigurasjon som sier dh none ved siden av et sertifikat som sier RSA, pluss en gnagende mistanke om at en av dem må være feil. Ingenting er feil. Sertifikatet signerer og autentiserer; nøkkelutvekslingen etablerer en felles hemmelighet. Det er to forskjellige jobber i samme håndtrykk, og TLS lar et RSA-sertifikat autentisere et håndtrykk som bruker efemær elliptisk-kurve-avtale.

Forvirringen kommer vanligvis med en migrasjonsveiledning. Den sier at DH-parameterfilen skal erstattes med dh none, leseren legger merke til at sertifikatet ikke er et elliptisk-kurve-sertifikat, og de to fakta behandles som en motsetning.

Hvorfor de to innstillingene virker beslektet

Den eldre OpenVPN-konfigurasjonen krevde en DH-parameterfil fordi endelig-felt Diffie-Hellman trenger domeneparametere som begge parter er enige om. dh-direktivet pekte på den filen. Når en utrulling går over til ECDH, kommer parameterne fra en navngitt kurve i stedet, og filen er ikke lenger nødvendig, noe dh none uttrykker.

Sertifikater er en separat akse. De bærer en offentlig nøkkel og en signatur som beviser serverens identitet, og den nøkkelen kan være RSA eller elliptisk kurve uavhengig av hvordan sesjonsnøkkelen avtales. Et håndtrykk som bruker ECDHE til nøkkelavtale og RSA til autentisering, er vanlig og bredt utrullet.

Navngivningen gjør overlappingen verre. Elliptisk kurve vises i både ECDHE- og ECDSA-suitenavn, så det er lett å anta at enhver tilkobling som nevner en kurve, må involvere et kurvesertifikat. Det gjør den ikke.

Slik leser du et TLS 1.2-suitenavn riktig

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 beskriver postbeskyttelse og hashen som brukes i håndtrykket.

En ECDHE-ECDSA-suite bruker samme nøkkelutvekslingsfamilie med en annen autentiseringsmetode, så den trenger et elliptisk-kurve-sertifikat. En DHE-RSA-suite bruker efemær endelig-felt Diffie-Hellman med RSA-autentisering, og den trenger faktisk DH-parametere.

Les et suitenavn fra venstre mot høyre og tilordne hver del til jobben sin. Når tokenene er skilt, endres spørsmålet fra «passer sertifikatet mitt til dh none» til «tillater serveren min en suite hvis nøkkelutveksling ikke trenger en DH-fil».

Hva dh none faktisk deaktiverer

dh none ber serveren om ikke å laste inn en endelig-felt DH-parameterfil. Det deaktiverer ikke autentisering, sertifikatvalidering eller selve TLS. Det krever imidlertid at den avtalte nøkkelutvekslingen ikke trenger disse parameterne, noe som i praksis betyr en ECDHE-suite eller et TLS 1.3-håndtrykk.

Det er fra dette kravet bruddet kommer. Hvis serverens TLS-sifferpolitikk er begrenset til DHE-suiter, eller en klient bare tilbyr dem, etterlater fjerningen av parameterfilen ingen brukbar nøkkelutvekslingsmetode, og håndtrykket mislykkes. Feilen vises vanligvis under håndtrykket for kontrollkanalen, før noen brukerautentisering. Les sifferlisten før du gir den manglende filen skylden.

På elliptisk-kurve-siden velges kurven av serverens TLS-konfigurasjon, og OpenVPN tilbyr et alternativ for å velge den på eldre grener. TLS 1.3 håndterer gruppeavtalen inne i protokollen og konsulterer ikke DH-filen i det hele tatt.

dh none er ikke i seg selv en sikkerhetsnedgradering. Styrken i utvekslingen avhenger da av kurven og suiten som faktisk avtales, og derfor er neste steg å se på hva partene valgte, ikke på filen som mangler.

Bekreft avtalen før du redigerer

Øk detaljnivået for serveren og klienten, og les kontrollkanallinjen som OpenVPN skriver ut etter en tilkobling. Den angir TLS-versjonen og den avtalte sifferen, og rapporterer nøkkeltypen til motpartens sertifikat. Den ene linjen svarer på spørsmålet konfigurasjonsfilen bare antyder.

Hvis den viser TLS 1.2 med en ECDHE-RSA-suite og et RSA-sertifikat, er kombinasjonen nøyaktig det dh none forventer, og det er ingenting å reparere. Hvis den viser en DHE-suite eller et håndtrykksfeil uten felles siffer, ligger løsningen i sifferpolitikken eller klientens evner, ikke i sertifikatet.

Test den eldste klienten du har tenkt å støtte, fordi en aktuell klient kan avtale TLS 1.3 mens en eldre er begrenset til TLS 1.2-suiter. Hvis den eldste klienten ikke har noen overlapping, utvider du de tillatte suitene eller oppgraderer det endepunktet.

Slå ikke av sertifikatvalidering for å komme forbi et håndtrykksfeil. Feilen forteller deg at partene ikke klarte å bli enige om en nøkkelutveksling, og å slå av kontrollen fjerner identitetsgarantien uten å løse avtalen.

Sjekkliste: er sertifikatet RSA, er en ECDHE-suite tillatt, viser loggen den suiten, og avtaler den eldste støttede klienten den også? Hvis alle fire er ja, gjør dh none jobben sin.