Ar RSA sertifikatas gali veikti su dh none OpenVPN?

Štai serverio konfigūracija, kuri šalia sertifikato su RSA nurodo dh none, be to, erzina įtarimas, kad vienas iš jų turi būti neteisingas. Niekas nėra neteisinga. Sertifikatas pasirašo ir autentifikuoja; raktų mainai sukuria bendrą paslaptį. Tai du skirtingi darbai tame pačiame rankos paspaudime, ir TLS leidžia RSA sertifikatui autentifikuoti rankos paspaudimą, kuris naudoja efemerišką elipsės kreivės susitarimą.

Sumišimas dažniausiai ateina su migracijos vadovu. Jis sako pakeisti DH parametrų failą į dh none, skaitytojas pastebi, kad sertifikatas nėra elipsės kreivės sertifikatas, ir abu faktai traktuojami kaip prieštaravimas.

Kodėl abu nustatymai atrodo susiję

Senoji OpenVPN konfigūracija reikalavo DH parametrų failo, nes baigtinio lauko Diffie-Hellman reikia srities parametrų, dėl kurių susitaria abi pusės. dh direktyva rodė į tą failą. Kai diegimas pereina prie ECDH, parametrai ateina iš įvardytos kreivės, ir failo nebereikia, ką išreiškia dh none.

Sertifikatai yra atskira ašis. Jie neša viešąjį raktą ir parašą, kurie įrodo serverio tapatybę, ir tas raktas gali būti RSA arba elipsės kreivės, nepriklausomai nuo to, kaip sutariama dėl sesijos rakto. Rankos paspaudimas, kuris naudoja ECDHE raktų susitarimui ir RSA autentifikavimui, yra įprastas ir plačiai diegtas.

Pavadinimai dar labiau padidina sutapimą. Elipsės kreivė pasirodo ir ECDHE, ir ECDSA rinkinių pavadinimuose, todėl lengva manyti, kad bet kuri jungtis, minima kreivę, turi turėti kreivės sertifikatą. Taip nėra.

Kaip teisingai skaityti TLS 1.2 rinkinio pavadinimą

Paimkite ECDHE-RSA-AES256-GCM-SHA384. Pirmasis žetonas yra raktų mainų šeima: efemeriškas elipsės kreivės Diffie-Hellman. Antrasis yra autentifikavimo šeima: RSA. Likusi dalis apibūdina įrašų apsaugą ir rankos paspaudime naudojamą maišą.

ECDHE-ECDSA rinkinys naudoja tą pačią raktų mainų šeimą su kitu autentifikavimo metodu, todėl jam reikia elipsės kreivės sertifikato. DHE-RSA rinkinys naudoja baigtinio lauko efemerišką Diffie-Hellman su RSA autentifikavimu, ir tam tikrai reikia DH parametrų.

Skaitykite rinkinio pavadinimą iš kairės į dešinę ir priskirkite kiekvieną dalį jos darbui. Atskyrus žetonus, klausimas pasikeičia iš „ar mano sertifikatas atitinka dh none“ į „ar mano serveris leidžia rinkinį, kurio raktų mainams nereikia DH failo“.

Ką dh none iš tikrųjų išjungia

dh none nurodo serveriui neįkelti baigtinio lauko DH parametrų failo. Jis neišjungia autentifikavimo, sertifikatų tikrinimo ar paties TLS. Tačiau jis reikalauja, kad suderėti raktų mainai būtų tokie, kuriems nereikia tų parametrų, o praktiškai tai reiškia ECDHE rinkinį arba TLS 1.3 rankos paspaudimą.

Būtent iš šio reikalavimo kyla gedimas. Jei serverio TLS šifrų politika apribota DHE rinkiniais arba klientas siūlo tik juos, pašalinus parametrų failą nelieka jokio tinkamo raktų mainų metodo ir rankos paspaudimas nepavyksta. Klaida paprastai pasirodo valdymo kanalo rankos paspaudimo metu, prieš bet kokį vartotojo autentifikavimą. Perskaitykite šifrų sąrašą prieš kaltindami trūkstamą failą.

Elipsės kreivės pusėje kreivę parenka serverio TLS konfigūracija, o OpenVPN senesnėse šakose siūlo galimybę ją pasirinkti. TLS 1.3 tvarko grupės derybas protokolo viduje ir visiškai nesikreipia į DH failą.

dh none pats savaime nėra saugumo sumažinimas. Mainų stiprumas tada priklauso nuo kreivės ir rinkinio, dėl kurių tikrai susitarta, todėl kitas žingsnis yra pažiūrėti, ką pasirinko šalys, o ne trūkstamą failą.

Patvirtinti derybas prieš redaguojant

Padidinkite serverio ir kliento išsamumą ir perskaitykite valdymo kanalo eilutę, kurią OpenVPN išspausdina po prisijungimo. Ji nurodo TLS versiją ir suderėtą šifrą bei praneša apie partnerio sertifikato rakto tipą. Ta viena eilutė atsako į klausimą, kurį konfigūracijos failas tik užsimena.

Jei rodoma TLS 1.2 su ECDHE-RSA rinkiniu ir RSA sertifikatu, derinys yra būtent tai, ko tikisi dh none, ir nieko taisyti nereikia. Jei rodoma DHE rinkinys arba rankos paspaudimo gedimas be bendro šifro, sprendimas yra šifrų politikoje arba kliento galimybėse, o ne sertifikate.

Išbandykite seniausią klientą, kurį ketinate palaikyti, nes dabartinis klientas gali suderėti TLS 1.3, o senesnis apsiriboja TLS 1.2 rinkiniais. Jei seniausias klientas neturi sutapimo, išplėskite leidžiamus rinkinius arba atnaujinkite tą galinį tašką.

Neišjunkite sertifikatų tikrinimo, kad apeitumėte rankos paspaudimo gedimą. Gedimas jums sako, kad šalys negalėjo susitarti dėl raktų mainų, o patikrinimo išjungimas pašalina tapatybės garantiją neišsprendus susitarimo.

Kontrolinis sąrašas: ar sertifikatas RSA, ar leidžiamas ECDHE rinkinys, ar žurnale matomas tas rinkinys ir ar seniausias palaikomas klientas taip pat jį suderi? Jei visi keturi atsakymai taip, dh none atlieka savo darbą.