Kas RSA-sertifikaat saab OpenVPN-is dh none'iga töötada?

Siin on serveri konfiguratsioon, mis ütleb dh none RSA-sertifikaadi kõrval, pluss tüütu kahtlus, et üks neist peab vale olema. Miski pole vale. Sertifikaat allkirjastab ja autendib; võtmevahetus loob ühise saladuse. Need on kaks erinevat tööd samas kätluses ja TLS lubab RSA-sertifikaadil autentida kätlust, mis kasutab efemeerset elliptilise kõvera kokkulepet.

Segadus tuleb tavaliselt migratsioonijuhendiga. See ütleb DH-parameetrite fail dh none-ga asendada, lugeja märkab, et sertifikaat ei ole elliptilise kõvera sertifikaat, ja neid kahte fakti käsitletakse vastuoluna.

Miks need kaks seadet seotud tunduvad

OpenVPN-i vanem konfiguratsioon nõudis DH-parameetrite faili, sest lõpliku välja Diffie-Hellman vajab domeeniparameetreid, millega mõlemad pooled nõustuvad. Direktiiv dh osutas sellele failile. Kui juurutus läheb üle ECDH-le, tulevad parameetrid hoopis nimetatud kõveralt ja faili pole enam vaja, mida väljendab dh none.

Sertifikaadid on eraldi telg. Need kannavad avalikku võtit ja allkirja, mis tõestavad serveri identiteeti, ja see võti võib olla RSA või elliptiline kõver sõltumata sellest, kuidas seansi võti kokku lepitakse. Kätlus, mis kasutab võtmekokkuleppeks ECDHE-d ja autentimiseks RSA-d, on tavaline ja laialt juurutatud.

Nimetamine teeb kattuvuse hullemaks. Elliptiline kõver esineb nii ECDHE kui ECDSA komplektinimedes, seega on lihtne eeldada, et iga kõverat mainiv ühendus peab sisaldama kõvera sertifikaati. See pole nii.

Kuidas TLS 1.2 komplektinime õigesti lugeda

Võtke ECDHE-RSA-AES256-GCM-SHA384. Esimene märk on võtmevahetuse perekond: efemeerne elliptilise kõvera Diffie-Hellman. Teine on autentimise perekond: RSA. Ülejäänu kirjeldab kirje kaitset ja kätluses kasutatavat räsi.

Komplekt ECDHE-ECDSA kasutab sama võtmevahetuse perekonda teistsuguse autentimismeetodiga, seega vajab see elliptilise kõvera sertifikaati. Komplekt DHE-RSA kasutab RSA-autentimisega lõpliku välja efemeerset Diffie-Hellmani ja see vajab tõesti DH-parameetreid.

Lugege komplektinime vasakult paremale ja määrake iga osa oma tööle. Kui märgid on eraldatud, muutub küsimus «kas minu sertifikaat sobib dh none'iga» küsimuseks «kas minu server lubab komplekti, mille võtmevahetus ei vaja DH-faili».

Mida dh none tegelikult välja lülitab

dh none ütleb serverile, et see ei laadiks lõpliku välja DH-parameetrite faili. See ei lülita välja autentimist, sertifikaatide valideerimist ega TLS-i ennast. See nõuab aga, et kokku lepitud võtmevahetus ei vajaks neid parameetreid, mis praktikas tähendab ECDHE-komplekti või TLS 1.3 kätlust.

Just sellest nõudest tuleb katkestus. Kui serveri TLS-šifrite poliitika on piiratud DHE-komplektidega või klient pakub ainult neid, siis parameetrifaili eemaldamine ei jäta ühtegi kasutatavat võtmevahetusmeetodit ja kätlus ebaõnnestub. Viga ilmub tavaliselt juhtkanali kätluse ajal, enne mis tahes kasutaja autentimist. Lugege šifrite loendit enne, kui süüdistate puuduvat faili.

Elliptilise kõvera poolel valib kõvera serveri TLS-konfiguratsioon ja OpenVPN pakub vanemates harudes selle valimise võimalust. TLS 1.3 käsitleb rühma läbirääkimist protokolli sees ega konsulteeri DH-failiga üldse.

dh none iseenesest ei ole turvataseme langetamine. Vahetuse tugevus sõltub siis kõverast ja komplektist, mille osas tegelikult kokku lepitakse, seetõttu on järgmine samm vaadata, mida osapooled valisid, mitte puuduvat faili.

Läbirääkimise kinnitamine enne muutmist

Tõstke serveri ja kliendi detailsust ning lugege juhtkanali rida, mille OpenVPN pärast ühendust prindib. See nimetab TLS-i versiooni ja kokku lepitud šifri ning teatab partneri sertifikaadi võtmetüübi. See üks rida vastab küsimusele, mida konfiguratsioonifail ainult vihjab.

Kui see näitab TLS 1.2 koos ECDHE-RSA komplekti ja RSA-sertifikaadiga, on kombinatsioon täpselt see, mida dh none ootab, ja parandada pole midagi. Kui see näitab DHE-komplekti või kätluse ebaõnnestumist ilma ühise šifrita, on parandus šifripoliitikas või kliendi võimalustes, mitte sertifikaadis.

Testige kõige vanemat klienti, mida kavatsete toetada, sest praegune klient võib kokku leppida TLS 1.3, samal ajal kui vanem on piiratud TLS 1.2 komplektidega. Kui kõige vanemal kliendil puudub kattuvus, laiendage lubatud komplekte või uuendage see lõpp-punkt.

Ärge lülitage sertifikaadi kontrolli välja, et kätluse ebaõnnestumisest mööda saada. Ebaõnnestumine ütleb teile, et osapooled ei suutnud võtmevahetuses kokku leppida, ja kontrolli väljalülitamine eemaldab identiteedigarantii ilma kokkulepet lahendamata.

Kontroll-loend: kas sertifikaat on RSA, kas ECDHE-komplekt on lubatud, kas logi näitab seda komplekti ja kas kõige vanem toetatud klient lepib ka selle kokku? Kui kõik neli on jah, teeb dh none oma tööd.