Kan ett RSA-certifikat fungera med dh none i OpenVPN?

Här är en serverkonfiguration som säger dh none bredvid ett certifikat som säger RSA, plus en gnagande misstanke om att ett av dem måste vara fel. Inget är fel. Certifikatet signerar och autentiserar; nyckelutbytet etablerar en gemensam hemlighet. Det är två olika jobb i samma handskakning, och TLS låter ett RSA-certifikat autentisera en handskakning som använder efemär elliptisk-kurva-överenskommelse.

Förvirringen kommer vanligtvis med en migreringsguide. Den säger att DH-parameterfilen ska ersättas med dh none, läsaren märker att certifikatet inte är ett elliptisk-kurva-certifikat, och de två fakta behandlas som en motsägelse.

Varför de två inställningarna verkar besläktade

Den äldre OpenVPN-konfigurationen krävde en DH-parameterfil eftersom ändligt-fält Diffie-Hellman behöver domänparametrar som båda sidor är överens om. Direktivet dh pekade på den filen. När en utrullning går över till ECDH kommer parametrarna i stället från en namngiven kurva, och filen behövs inte längre, vilket dh none uttrycker.

Certifikat är en separat axel. De bär en offentlig nyckel och en signatur som bevisar serverns identitet, och den nyckeln kan vara RSA eller elliptisk kurva oavsett hur sessionsnyckeln avtalas. En handskakning som använder ECDHE för nyckelavtal och RSA för autentisering är vanlig och brett utrullad.

Namngivningen förvärrar överlappningen. Elliptisk kurva förekommer i både ECDHE- och ECDSA-suitnamn, så det är lätt att anta att varje anslutning som nämner en kurva måste innehålla ett kurvcertifikat. Så är det inte.

Så läser du ett TLS 1.2-suitnamn korrekt

Ta ECDHE-RSA-AES256-GCM-SHA384. Den första token är nyckelutbytesfamiljen: efemär elliptisk-kurva Diffie-Hellman. Den andra är autentiseringsfamiljen: RSA. Resten beskriver postskydd och den hash som används i handskakningen.

En ECDHE-ECDSA-suite använder samma nyckelutbytesfamilj med en annan autentiseringsmetod, så den behöver ett elliptisk-kurva-certifikat. En DHE-RSA-suite använder efemär ändligt-fält Diffie-Hellman med RSA-autentisering, och den behöver faktiskt DH-parametrar.

Läs ett suitnamn från vänster till höger och tilldela varje del dess jobb. När tokens har separerats ändras frågan från »passar mitt certifikat till dh none« till »tillåter min server en suite vars nyckelutbyte inte behöver en DH-fil«.

Vad dh none faktiskt inaktiverar

dh none säger till servern att inte läsa in en ändligt-fält DH-parameterfil. Det inaktiverar inte autentisering, certifikatvalidering eller själva TLS. Det kräver dock att det förhandlade nyckelutbytet inte behöver dessa parametrar, vilket i praktiken betyder en ECDHE-suite eller en TLS 1.3-handskakning.

Det är från detta krav som felet kommer. Om serverns TLS-chifferpolicy är begränsad till DHE-suiter, eller en klient bara erbjuder dem, lämnar borttagningen av parameterfilen ingen användbar nyckelutbytesmetod och handskakningen misslyckas. Felet visas vanligtvis under handskakningen av kontrollkanalen, före någon användarautentisering. Läs chifferlistan innan du skyller på den saknade filen.

På elliptisk-kurva-sidan väljs kurvan av serverns TLS-konfiguration, och OpenVPN erbjuder ett alternativ att välja den på äldre grenar. TLS 1.3 hanterar gruppförhandlingen inne i protokollet och konsulterar inte DH-filen alls.

dh none är inte i sig en säkerhetsnedgradering. Styrkan i utbytet beror då på kurvan och suiten som faktiskt förhandlas, och därför är nästa steg att titta på vad parterna valde, inte på filen som saknas.

Bekräfta förhandlingen innan du redigerar

Höj detaljnivån för servern och klienten och läs kontrollkanallinjen som OpenVPN skriver ut efter en anslutning. Den anger TLS-versionen och det förhandlade chiffret och rapporterar motpartens certifikatnyckeltyp. Den enda raden svarar på frågan som konfigurationsfilen bara antyder.

Om den visar TLS 1.2 med en ECDHE-RSA-suite och ett RSA-certifikat är kombinationen exakt vad dh none förväntar sig, och det finns inget att reparera. Om den visar en DHE-suite eller ett handskakningsfel utan gemensamt chiffer ligger lösningen i chifferpolicyn eller klientens förmåga, inte i certifikatet.

Testa den äldsta klienten du tänker stödja, eftersom en aktuell klient kan förhandla TLS 1.3 medan en äldre är begränsad till TLS 1.2-suiter. Om den äldsta klienten inte har någon överlappning, utöka de tillåtna suiterna eller uppgradera den slutpunkten.

Stäng inte av certifikatverifieringen för att komma förbi ett handskakningsfel. Felet säger att parterna inte kunde enas om ett nyckelutbyte, och att stänga av kontrollen tar bort identitetsgarantin utan att lösa avtalet.

Checklista: är certifikatet RSA, är en ECDHE-suite tillåten, visar loggen den suiten, och förhandlar den äldsta stödda klienten den också? Om alla fyra är ja gör dh none sitt jobb.