Kan een RSA-certificaat werken met dh none in OpenVPN?

Hier is een serverconfiguratie die dh none vermeldt naast een certificaat dat RSA zegt, plus het knagende vermoeden dat een van beide verkeerd moet zijn. Niets is verkeerd. Het certificaat ondertekent en authenticeert; de sleuteluitwisseling stelt een gedeeld geheim vast. Dat zijn twee verschillende taken in dezelfde handshake, en TLS staat een RSA-certificaat toe een handshake te authenticeren die tijdelijke elliptische-kromme-overeenkomst gebruikt.

De verwarring komt meestal met een migratiegids. Die zegt het DH-parameterbestand te vervangen door dh none, de lezer merkt dat het certificaat geen elliptische-kromme-certificaat is, en de twee feiten worden als een tegenspraak behandeld.

Waarom de twee instellingen verwant lijken

De oudere OpenVPN-configuratie vroeg om een DH-parameterbestand omdat eindige-veld Diffie-Hellman domeinparameters nodig heeft waarover beide kanten het eens zijn. De dh-richtlijn wees naar dat bestand. Wanneer een uitrol overstapt op ECDH, komen de parameters in plaats daarvan van een benoemde kromme, en het bestand is niet meer nodig, wat dh none uitdrukt.

Certificaten zijn een aparte as. Ze dragen een openbare sleutel en een handtekening die de identiteit van de server bewijzen, en die sleutel kan RSA of elliptische kromme zijn, ongeacht hoe de sessiesleutel wordt overeengekomen. Een handshake die ECDHE gebruikt voor sleutelovereenkomst en RSA voor authenticatie is gewoon en breed uitgerold.

De naamgeving verergert de overlap. Elliptische kromme komt voor in zowel ECDHE- als ECDSA-suitenaam, dus het is gemakkelijk aan te nemen dat elke verbinding die een kromme noemt een kromme-certificaat moet bevatten. Dat is niet zo.

Een TLS 1.2-suitenaam correct lezen

Neem ECDHE-RSA-AES256-GCM-SHA384. Het eerste token is de sleuteluitwisselingsfamilie: tijdelijke elliptische-kromme Diffie-Hellman. Het tweede is de authenticatiefamilie: RSA. De rest beschrijft recordbescherming en de hash die in de handshake wordt gebruikt.

Een ECDHE-ECDSA-suite gebruikt dezelfde sleuteluitwisselingsfamilie met een andere authenticatiemethode, dus heeft een elliptische-kromme-certificaat nodig. Een DHE-RSA-suite gebruikt tijdelijke eindige-veld Diffie-Hellman met RSA-authenticatie, en die heeft inderdaad DH-parameters nodig.

Lees een suitenaam van links naar rechts en wijs elk deel zijn taak toe. Zodra de tokens gescheiden zijn, verandert de vraag van «past mijn certificaat bij dh none» naar «staat mijn server een suite toe waarvan de sleuteluitwisseling geen DH-bestand nodig heeft».

Wat dh none werkelijk uitschakelt

dh none zegt tegen de server dat hij geen eindige-veld DH-parameterbestand moet laden. Het schakelt authenticatie, certificaatvalidatie of TLS zelf niet uit. Het vereist wel dat de onderhandelde sleuteluitwisseling geen van die parameters nodig heeft, wat in de praktijk een ECDHE-suite of een TLS 1.3-handshake betekent.

Juist uit die eis komt de breuk voort. Als het TLS-sifrebeleid van de server beperkt is tot DHE-suites, of een client biedt alleen die aan, dan laat het verwijderen van het parameterbestand geen bruikbare sleuteluitwisselingsmethode over en mislukt de handshake. De fout verschijnt meestal tijdens de handshake van het controlekanaal, vóór enige gebruikersauthenticatie. Lees de siferlijst voordat je het ontbrekende bestand de schuld geeft.

Aan de kant van de elliptische kromme wordt de kromme gekozen door de TLS-configuratie van de server, en OpenVPN biedt een optie om die op oudere takken te kiezen. TLS 1.3 regelt de groeponderhandeling binnen het protocol en raadpleegt het DH-bestand helemaal niet.

dh none is op zichzelf geen beveiligingsverlaging. De sterkte van de uitwisseling hangt dan af van de kromme en suite die werkelijk worden onderhandeld, daarom is de volgende stap kijken wat de peers kozen en niet het ontbrekende bestand.

De onderhandeling bevestigen voordat je bewerkt

Verhoog de uitgebreidheid van server en client en lees de lijn van het controlekanaal die OpenVPN na een verbinding afdrukt. Die noemt de TLS-versie en de onderhandelde sifer, en meldt het sleuteltype van het certificaat van de tegenpartij. Die ene regel beantwoordt de vraag die het configuratiebestand alleen suggereert.

Als die TLS 1.2 toont met een ECDHE-RSA-suite en een RSA-certificaat, is de combinatie precies wat dh none verwacht, en er is niets te repareren. Als die een DHE-suite of een handshakefout zonder gemeenschappelijke sifer toont, ligt de oplossing in het sifrebeleid of de mogelijkheden van de client, niet in het certificaat.

Test de oudste client die je wilt ondersteunen, want een huidige client kan TLS 1.3 onderhandelen terwijl een oudere beperkt is tot TLS 1.2-suites. Als de oudste client geen overlap heeft, breid dan de toegestane suites uit of werk dat eindpunt bij.

Schakel certificaatverificatie niet uit om een handshakefout te omzeilen. De fout zegt je dat de peers het niet eens konden worden over een sleuteluitwisseling, en het uitschakelen van de controle verwijdert de identiteitsgarantie zonder de overeenkomst op te lossen.

Checklist: is het certificaat RSA, is een ECDHE-suite toegestaan, toont het log die suite, en onderhandelt de oudste ondersteunde client die ook? Als alle vier ja zijn, doet dh none zijn werk.