Môže certifikát RSA fungovať s dh none v OpenVPN?

Tu je konfigurácia servera, ktorá vedľa certifikátu s RSA uvádza dh none, plus otravné podozrenie, že jedno z toho musí byť nesprávne. Nič nie je nesprávne. Certifikát podpisuje a autentizuje; výmena kľúčov vytvára spoločné tajomstvo. Sú to dve rôzne úlohy v tom istom handshaku a TLS umožňuje certifikátu RSA autentizovať handshake, ktorý používa efemérnu dohodu na eliptickej krivke.

Zmena zvyčajne prichádza s migračným sprievodcom. Ten hovorí nahradiť súbor DH parametrov za dh none, čitateľ si všimne, že certifikát nie je certifikát eliptickej krivky, a oba fakty sa považujú za rozpor.

Prečo obe nastavenia vyzerajú súvisiace

Staršia konfigurácia OpenVPN vyžadovala súbor DH parametrov, pretože Diffie-Hellman v konečnom poli potrebuje doménové parametre, na ktorých sa obe strany zhodnú. Direktíva dh ukazovala na tento súbor. Keď nasadenie prejde na ECDH, parametre pochádzajú z pomenovanej krivky a súbor už nie je potrebný, čo vyjadruje dh none.

Certifikáty sú samostatná os. Nesú verejný kľúč a podpis, ktoré dokazujú identitu servera, a tento kľúč môže byť RSA alebo eliptická krivka bez ohľadu na to, ako sa dohodne kľúč relácie. Handshake, ktorý používa ECDHE na dohodu o kľúči a RSA na autentizáciu, je bežný a široko nasadený.

Pomenovanie prekrývanie zhoršuje. Eliptická krivka sa objavuje v názvoch sád ECDHE aj ECDSA, takže je ľahké predpokladať, že každé spojenie spomínajúce krivku musí obsahovať certifikát krivky. Nie je to tak.

Ako správne čítať názov sady TLS 1.2

Vezmite ECDHE-RSA-AES256-GCM-SHA384. Prvý token je rodina výmeny kľúčov: efemérny Diffie-Hellman na eliptickej krivke. Druhý je rodina autentizácie: RSA. Zvyšok opisuje ochranu záznamov a hash použitý v handshaku.

Sada ECDHE-ECDSA používa rovnakú rodinu výmeny kľúčov s inou metódou autentizácie, takže potrebuje certifikát eliptickej krivky. Sada DHE-RSA používa efemérny Diffie-Hellman v konečnom poli s autentizáciou RSA a tá naozaj potrebuje DH parametre.

Čítajte názov sady zľava doprava a priraďte každú časť jej úlohe. Po oddelení tokenov sa otázka mení z „zodpovedá môj certifikát dh none“ na „povoľuje môj server sadu, ktorej výmena kľúčov nepotrebuje súbor DH“.

Čo dh none skutočne vypína

dh none hovorí serveru, aby nenačítal súbor DH parametrov v konečnom poli. Nevypína autentizáciu, overovanie certifikátov ani samotné TLS. Vyžaduje však, aby dohodnutá výmena kľúčov nepotrebovala tieto parametre, čo v praxi znamená sadu ECDHE alebo handshake TLS 1.3.

Práve z tejto požiadavky vzniká porucha. Ak je politika šifier TLS servera obmedzená na sady DHE alebo klient ponúka len tie, odstránenie súboru parametrov nezanechá žiadnu použiteľnú metódu výmeny kľúčov a handshake zlyhá. Chyba sa zvyčajne objaví počas handshaku riadiaceho kanála, pred akoukoľvek autentizáciou používateľa. Prečítajte si zoznam šifier, skôr než obviníte chýbajúci súbor.

Na strane eliptickej krivky krivku vyberá konfigurácia TLS servera a OpenVPN ponúka možnosť vybrať ju na starších vetvách. TLS 1.3 rieši dohodu o skupine vnútri protokolu a súbor DH vôbec nekonzultuje.

dh none samo o sebe nie je znížením bezpečnosti. Sila výmeny potom závisí od krivky a sady, ktoré sa skutočne dohodnú, a preto je ďalším krokom pozrieť sa, čo si strany vybrali, a nie na chýbajúci súbor.

Potvrdenie dohody pred úpravou

Zvýšte podrobnosť servera a klienta a prečítajte riadok riadiaceho kanála, ktorý OpenVPN vypíše po pripojení. Uvádza verziu TLS a dohodnutú šifru a hlási typ kľúča certifikátu protistrany. Ten jediný riadok odpovedá na otázku, ktorú konfiguračný súbor len naznačuje.

Ak ukazuje TLS 1.2 so sadou ECDHE-RSA a certifikátom RSA, kombinácia je presne to, čo dh none očakáva, a nie je čo opravovať. Ak ukazuje sadu DHE alebo zlyhanie handshaku bez spoločnej šifry, oprava je v politike šifier alebo schopnostiach klienta, nie v certifikáte.

Otestujte najstaršieho klienta, ktorého hodláte podporovať, pretože aktuálny klient môže dohodnúť TLS 1.3, zatiaľ čo starší je obmedzený na sady TLS 1.2. Ak sa najstarší klient neprekrýva, buď rozšírte povolené sady, alebo aktualizujte tento koncový bod.

Nevypínajte overovanie certifikátov, aby ste obišli zlyhanie handshaku. Zlyhanie vám hovorí, že sa strany nedokázali dohodnúť na výmene kľúčov, a vypnutie kontroly odstráni záruku identity bez vyriešenia dohody.

Kontrolný zoznam: je certifikát RSA, je povolená sada ECDHE, ukazuje protokol túto sadu a dohodne ju aj najstarší podporovaný klient? Ak sú všetky štyri odpovede áno, dh none si robí svoju prácu.