Může certifikát RSA fungovat s dh none v OpenVPN?

Tady je konfigurace serveru, která vedle certifikátu s RSA uvádí dh none, plus otravné podezření, že jedno z toho musí být špatně. Nic špatně není. Certifikát podepisuje a autentizuje; výměna klíčů vytváří sdílené tajemství. Jsou to dva různé úkoly v témže handshake a TLS umožňuje certifikátu RSA autentizovat handshake, který používá efemérní dohodu na eliptické křivce.

Zmatek obvykle přichází s migračním průvodcem. Ten říká nahradit soubor DH parametrů za dh none, čtenář si všimne, že certifikát není certifikát eliptické křivky, a oba fakty se považují za rozpor.

Proč obě nastavení vypadají související

Starší konfigurace OpenVPN vyžadovala soubor DH parametrů, protože Diffie-Hellman v konečném poli potřebuje parametry domény, na kterých se obě strany shodnou. Direktiva dh na tento soubor ukazovala. Když nasazení přejde na ECDH, parametry místo toho přicházejí z pojmenované křivky a soubor už není potřeba, což vyjadřuje dh none.

Certifikáty jsou samostatná osa. Nesou veřejný klíč a podpis, které dokazují identitu serveru, a tento klíč může být RSA nebo eliptická křivka bez ohledu na to, jak se dohodne klíč relace. Handshake, který používá ECDHE pro dohodu o klíči a RSA pro autentizaci, je běžný a široce nasazený.

Pojmenování překryv zhoršuje. Eliptická křivka se objevuje v názvech sad ECDHE i ECDSA, takže je snadné předpokládat, že každé spojení zmiňující křivku musí zahrnovat certifikát křivky. Není tomu tak.

Jak správně číst název sady TLS 1.2

Vezměte ECDHE-RSA-AES256-GCM-SHA384. První token je rodina výměny klíčů: efemérní Diffie-Hellman na eliptické křivce. Druhý je rodina autentizace: RSA. Zbytek popisuje ochranu záznamů a hash použitý v handshake.

Sada ECDHE-ECDSA používá stejnou rodinu výměny klíčů s jinou metodou autentizace, takže potřebuje certifikát eliptické křivky. Sada DHE-RSA používá efemérní Diffie-Hellman v konečném poli s autentizací RSA a ta opravdu potřebuje DH parametry.

Čtěte název sady zleva doprava a přiřaďte každou část jejímu úkolu. Jakmile se tokeny oddělí, otázka se změní z „odpovídá můj certifikát dh none“ na „povoluje můj server sadu, jejíž výměna klíčů nepotřebuje soubor DH“.

Co dh none skutečně vypíná

dh none říká serveru, aby nenačítal soubor DH parametrů pro konečné pole. Nevypíná autentizaci, ověřování certifikátů ani samotné TLS. Vyžaduje však, aby dohodnutá výměna klíčů nepotřebovala tyto parametry, což v praxi znamená sadu ECDHE nebo handshake TLS 1.3.

Právě z tohoto požadavku vzniká porucha. Pokud je politika šifer TLS serveru omezena na sady DHE nebo klient nabízí jen je, odstranění souboru parametrů nezanechá žádnou použitelnou metodu výměny klíčů a handshake selže. Chyba se obvykle objeví během handshake řídicího kanálu, před jakoukoli autentizací uživatele. Přečtěte si seznam šifer, než obviníte chybějící soubor.

Na straně eliptické křivky křivku vybírá TLS konfigurace serveru a OpenVPN nabízí možnost ji zvolit na starších větvích. TLS 1.3 řeší dohodu o skupině uvnitř protokolu a soubor DH vůbec nekonzultuje.

dh none samo o sobě není snížením zabezpečení. Síla výměny pak závisí na křivce a sadě, které se skutečně dohodnou, a proto je dalším krokem podívat se, co si strany vybraly, a ne na chybějící soubor.

Potvrzení dohody před úpravou

Zvyšte podrobnost serveru a klienta a přečtěte řádek řídicího kanálu, který OpenVPN vypíše po připojení. Uvádí verzi TLS a dohodnutou šifru a hlásí typ klíče certifikátu protistrany. Ten jediný řádek odpovídá na otázku, kterou konfigurační soubor jen naznačuje.

Pokud ukazuje TLS 1.2 se sadou ECDHE-RSA a certifikátem RSA, kombinace je přesně to, co dh none očekává, a není co opravovat. Pokud ukazuje sadu DHE nebo selhání handshake bez společné šifry, oprava je v politice šifer nebo schopnostech klienta, ne v certifikátu.

Otestujte nejstaršího klienta, kterého hodláte podporovat, protože současný klient může dohodnout TLS 1.3, zatímco starší je omezen na sady TLS 1.2. Pokud se nejstarší klient nepřekrývá, buď rozšiřte povolené sady, nebo tento koncový bod aktualizujte.

Nevypínejte ověřování certifikátů, abyste obešli selhání handshake. Selhání vám říká, že se strany nedokázaly dohodnout na výměně klíčů, a vypnutí kontroly odstraní záruku identity, aniž by řešilo dohodu.

Kontrolní seznam: je certifikát RSA, je povolena sada ECDHE, ukazuje protokol tuto sadu a dohodne ji i nejstarší podporovaný klient? Pokud jsou všechny čtyři odpovědi ano, dh none dělá svou práci.