Működhet egy RSA-tanúsítvány a dh none beállítással az OpenVPN-ben?

Itt egy szerverkonfiguráció, amely RSA-t mondó tanúsítvány mellett dh none állítást tartalmaz, plusz a kísértő gyanú, hogy valamelyikük biztosan hibás. Semmi sem hibás. A tanúsítvány aláír és hitelesít; a kulcscsere közös titkot hoz létre. Ez két külön feladat ugyanabban a kézfogásban, és a TLS lehetővé teszi, hogy egy RSA-tanúsítvány egy efemer elliptikus görbés megállapodást használó kézfogást hitelesítsen.

A zavar általában egy migrációs útmutatóval érkezik. Azt mondja, hogy a DH-paraméterfájlt dh none-ra kell cserélni, az olvasó észreveszi, hogy a tanúsítvány nem elliptikus görbés tanúsítvány, és a két tényt ellentmondásként kezelik.

Miért tűnik a két beállítás összefüggőnek

Az OpenVPN régebbi konfigurációja DH-paraméterfájlt kért, mert a véges testű Diffie-Hellman olyan tartományparamétereket igényel, amelyekben mindkét fél megegyezik. A dh utasítás arra a fájlra mutatott. Amikor egy telepítés ECDH-ra vált, a paraméterek helyette egy nevesített görbéből származnak, és a fájlra már nincs szükség, amit a dh none fejez ki.

A tanúsítványok külön tengelyt jelentenek. Nyilvános kulcsot és aláírást hordoznak, amelyek bizonyítják a szerver identitását, és ez a kulcs lehet RSA vagy elliptikus görbéjű, függetlenül attól, hogyan egyeznek meg a munkamenetkulcsban. Az a kézfogás, amely kulcsegyeztetésre ECDHE-t, hitelesítésre RSA-t használ, szokásos és széles körben telepített.

Az elnevezés súlyosbítja az átfedést. Az elliptikus görbe az ECDHE és az ECDSA suite-nevekben is megjelenik, ezért könnyű azt feltételezni, hogy minden görbét említő kapcsolatnak görbe-tanúsítványt kell tartalmaznia. Nem ez a helyzet.

Egy TLS 1.2 suite-név helyes olvasása

Vegyük a ECDHE-RSA-AES256-GCM-SHA384-t. Az első token a kulcscsere-család: efemer elliptikus görbés Diffie-Hellman. A második a hitelesítési család: RSA. A többi a rekordok védelmét és a kézfogásban használt hasht írja le.

A ECDHE-ECDSA suite ugyanazt a kulcscsere-családot használja más hitelesítési módszerrel, ezért elliptikus görbés tanúsítványt igényel. A DHE-RSA suite RSA-hitelesítéssel véges testű efemer Diffie-Hellmant használ, és annak valóban kellenek a DH-paraméterek.

Olvassuk a suite-nevet balról jobbra, és rendeljük minden részt a feladatához. Amint a tokenek elválnak, a kérdés «illeszkedik-e a tanúsítványom a dh none-hoz» helyett «enged-e a szerverem olyan suite-ot, amelynek kulcscseréjéhez nem kell DH-fájl».

Mit kapcsol ki valójában a dh none

A dh none arra utasítja a szervert, hogy ne töltsön be véges testű DH-paraméterfájlt. Nem kapcsolja ki a hitelesítést, a tanúsítványok érvényesítését vagy magát a TLS-t. Azt viszont megköveteli, hogy a megtárgyalt kulcscsere olyan legyen, amelyhez nincsenek szükség ezekre a paraméterekre, ami a gyakorlatban ECDHE suite-ot vagy TLS 1.3-as kézfogást jelent.

Ebből a követelményből ered a meghibásodás. Ha a szerver TLS-titkosítási szabályzata DHE suite-okra korlátozódik, vagy egy kliens csak azokat kínálja, a paraméterfájl eltávolítása nem hagy használható kulcscsere-módszert, és a kézfogás meghiúsul. A hiba általában a vezérlőcsatorna kézfogása közben, minden felhasználói hitelesítés előtt jelenik meg. Olvassuk el a titkosításlistát, mielőtt a hiányzó fájlt hibáztatnánk.

Az elliptikus görbés oldalon a görbét a szerver TLS-konfigurációja választja ki, és az OpenVPN a régebbi ágakon lehetőséget kínál a kiválasztására. A TLS 1.3 a protokollon belül kezeli a csoporttárgyalást, és egyáltalán nem nézi a DH-fájlt.

A dh none önmagában nem biztonsági visszalépés. A csere erőssége ezután a ténylegesen megtárgyalt görbétől és suite-tól függ, ezért a következő lépés az, hogy megnézzük, mit választottak a felek, és ne a hiányzó fájlt.

A tárgyalás megerősítése szerkesztés előtt

Növeljük a szerver és a kliens részletességét, és olvassuk el a vezérlőcsatorna sorát, amelyet az OpenVPN a kapcsolat után kinyomtat. Megnevezi a TLS-verziót és a megtárgyalt titkosítást, és jelenti a partner tanúsítványának kulcstípusát. Az az egyetlen sor válaszol arra a kérdésre, amelyre a konfigurációs fájl csak utal.

Ha TLS 1.2-t mutat ECDHE-RSA suite-tal és RSA-tanúsítvánnyal, a kombináció pontosan az, amit a dh none vár, és nincs mit javítani. Ha DHE suite-ot vagy közös titkosítás nélküli kézfogási hibát mutat, a javítás a titkosítási szabályzatban vagy a kliens képességeiben van, nem a tanúsítványban.

Teszteljük a legrégebbi klienst, amelyet támogatni kívánunk, mert egy jelenlegi kliens TLS 1.3-at tárgyalhat, míg egy régebbi a TLS 1.2 suite-okra korlátozódik. Ha a legrégebbi kliensnek nincs átfedése, vagy szélesítsük az engedélyezett suite-okat, vagy frissítsük azt a végpontot.

Ne kapcsoljuk ki a tanúsítvány-ellenőrzést egy kézfogási hiba megkerüléséhez. A hiba azt mondja, hogy a felek nem tudtak megegyezni a kulcscserében, és az ellenőrzés kikapcsolása eltávolítja az identitásgaranciát anélkül, hogy megoldaná a megállapodást.

Ellenőrzőlista: RSA-e a tanúsítvány, engedélyezett-e egy ECDHE suite, mutatja-e a napló azt a suite-ot, és megtárgyalja-e a legrégebbi támogatott kliens is? Ha mind a négy igen, a dh none végzi a dolgát.