Može li RSA certifikat raditi s dh none u OpenVPN-u?

Evo serverske konfiguracije koja pored certifikata s oznakom RSA navodi dh none, uz dosadnu sumnju da jedno od toga mora biti pogrešno. Ništa nije pogrešno. Certifikat potpisuje i autentificira; razmjena ključeva uspostavlja zajedničku tajnu. To su dva različita posla u istom rukovanju, a TLS dopušta da RSA certifikat autentificira rukovanje koje koristi efemerni dogovor na eliptičnoj krivulji.

Zabuna obično dolazi s vodičem za migraciju. On kaže da se datoteka s DH parametrima zamijeni s dh none, čitatelj primijeti da certifikat nije certifikat eliptične krivulje, i te se dvije činjenice tretiraju kao proturječje.

Zašto dvije postavke izgledaju povezane

Starija OpenVPN konfiguracija tražila je datoteku s DH parametrima jer Diffie-Hellman u konačnom polju treba parametre domene oko kojih se obje strane slažu. Direktiva dh pokazivala je na tu datoteku. Kada se instalacija prebaci na ECDH, parametri umjesto toga dolaze s imenovane krivulje i datoteka više nije potrebna, što izražava dh none.

Certifikati su zasebna os. Nose javni ključ i potpis koji dokazuju identitet servera, a taj ključ može biti RSA ili eliptična krivulja bez obzira na to kako se dogovara ključ sesije. Rukovanje koje koristi ECDHE za dogovor o ključu i RSA za autentifikaciju uobičajeno je i široko rasprostranjeno.

Imenovanje pogoršava preklapanje. Eliptična krivulja pojavljuje se i u nazivima ECDHE i ECDSA suiteova, pa je lako pretpostaviti da svaka veza koja spominje krivulju mora uključivati certifikat krivulje. Nije tako.

Kako ispravno čitati naziv TLS 1.2 suitea

Uzmite ECDHE-RSA-AES256-GCM-SHA384. Prvi token je obitelj razmjene ključeva: efemerni Diffie-Hellman na eliptičnoj krivulji. Drugi je obitelj autentifikacije: RSA. Ostatak opisuje zaštitu zapisa i hash koji se koristi u rukovanju.

ECDHE-ECDSA suite koristi istu obitelj razmjene ključeva s drugačijom metodom autentifikacije, pa mu treba certifikat eliptične krivulje. DHE-RSA suite koristi efemerni Diffie-Hellman u konačnom polju s RSA autentifikacijom i taj doista treba DH parametre.

Čitajte naziv suitea slijeva nadesno i dodijelite svaki dio njegovom poslu. Kad se tokeni razdvoje, pitanje se mijenja s „odgovara li moj certifikat dh none” na „dopušta li moj server suite čija razmjena ključeva ne treba DH datoteku”.

Što dh none zapravo isključuje

dh none govori serveru da ne učita datoteku DH parametara za konačno polje. On ne isključuje autentifikaciju, provjeru certifikata ni sam TLS. Zahtijeva pak da dogovorena razmjena ključeva bude ona koja ne treba te parametre, što u praksi znači ECDHE suite ili TLS 1.3 rukovanje.

Iz tog zahtjeva dolazi kvar. Ako je TLS politika šifri servera ograničena na DHE suiteove ili klijent nudi samo njih, uklanjanje datoteke s parametrima ne ostavlja nijednu upotrebljivu metodu razmjene ključeva i rukovanje ne uspijeva. Greška se obično pojavljuje tijekom rukovanja kontrolnog kanala, prije ikakve autentifikacije korisnika. Pročitajte popis šifri prije nego optužite datoteku koja nedostaje.

Na strani eliptične krivulje, krivulju bira TLS konfiguracija servera, a OpenVPN nudi opciju da je odaberete na starijim granama. TLS 1.3 obavlja dogovor o grupi unutar protokola i uopće ne provjerava DH datoteku.

dh none sam po sebi nije smanjenje sigurnosti. Snaga razmjene tada ovisi o krivulji i suiteu koji su stvarno dogovoreni, zato je sljedeći korak pogledati što su strane odabrale, a ne datoteku koja nedostaje.

Potvrda dogovora prije uređivanja

Povećajte detaljnost servera i klijenta i pročitajte redak kontrolnog kanala koji OpenVPN ispiše nakon veze. On navodi verziju TLS-a i dogovorenu šifru te prijavljuje tip ključa certifikata druge strane. Taj jedan redak odgovara na pitanje koje konfiguracijska datoteka samo implicira.

Ako pokazuje TLS 1.2 s ECDHE-RSA suiteom i RSA certifikatom, kombinacija je točno ono što dh none očekuje i nema što popravljati. Ako pokazuje DHE suite ili neuspjeh rukovanja bez zajedničke šifre, popravak je u politici šifri ili mogućnostima klijenta, ne u certifikatu.

Testirajte najstariji klijent koji namjeravate podržavati, jer aktualni klijent može dogovoriti TLS 1.3 dok je stariji ograničen na TLS 1.2 suiteove. Ako najstariji klijent nema preklapanja, proširite dopuštene suiteove ili nadogradite tu krajnju točku.

Ne isključujte provjeru certifikata da biste zaobišli neuspjeh rukovanja. Neuspjeh vam kaže da se strane nisu mogle dogovoriti o razmjeni ključeva, a isključivanje provjere uklanja jamstvo identiteta bez rješavanja dogovora.

Popis za provjeru: je li certifikat RSA, je li ECDHE suite dopušten, pokazuje li zapis taj suite i dogovara li ga i najstariji podržani klijent? Ako su sva četiri da, dh none radi svoj posao.