Kin in RSA-sertifikaat mei dh none yn OpenVPN wurkje?

Hjir is in serverkonfiguraasje dy't dh none seit njonken in sertifikaat dat RSA seit, plus in oanhingjend fermoeden dat ien fan beide ferkeard wêze moat. Neat is ferkeard. It sertifikaat ûndertekenet en autentisearret; de kaai-útwikseling fêstiget in mienskiplik geheim. Dat binne twa ferskillende taken yn deselde hântekening, en TLS lit in RSA-sertifikaat in hântekening autentisearje dy't efemere elliptyske-kromme-ôfspraak brûkt.

De betizing komt meastentiids mei in migraasjegids. Dy seit de DH-parameterleas te ferfangen troch dh none, de lêzer merkt dat it sertifikaat gjin elliptyske-kromme-sertifikaat is, en de beide feiten wurde as in tsjinspraak behannele.

Wêrom't de beide ynstellings besibbe lykje

De âldere konfiguraasje fan OpenVPN frege in DH-parameterleas om't Diffie-Hellman yn in einich fjild domeinparameters nedich hat dêr't beide kanten it oer iens binne. De dh-rjochtline wiisde nei dat bestân. As in ynstallaasje nei ECDH giet, komme de parameters fan in neamde kromme ynstee, en it bestân is net mear nedich, wat dh none útdrukt.

Sertifikaten binne in aparte as. Se drage in iepenbiere kaai en in hântekening dy't de identiteit fan de server bewize, en dy kaai kin RSA of elliptyske kromme wêze, hoe't de sesjekaai ek ôfpraat wurdt. In hântekening dy't ECDHE foar kaai-ôfspraak en RSA foar autentikaasje brûkt, is gewoan en breed útrôle.

De nammejouwing makket de oerlap slimmer. Elliptyske kromme komt yn sawol ECDHE- as ECDSA-suitnamme foar, dus it is maklik om oan te nimmen dat elke ferbining dy't in kromme neamt in krommesertifikaat befetsje moat. Dat is net sa.

Hoe't men in TLS 1.2-suitnamme goed lêst

Nim ECDHE-RSA-AES256-GCM-SHA384. It earste token is de kaai-útwikselingsfamylje: efemere elliptyske-kromme Diffie-Hellman. It twadde is de autentikaasjefamylje: RSA. De rest beskriuwt rekordbeskerming en de hash dy't yn 'e hântekening brûkt wurdt.

In ECDHE-ECDSA-suite brûkt deselde kaai-útwikselingsfamylje mei in oare autentikaasjemetoade, dus hat in elliptyske-kromme-sertifikaat nedich. In DHE-RSA-suite brûkt efemere einich-fjild Diffie-Hellman mei RSA-autentikaasje, en dy hat wol DH-parameters nedich.

Lês in suitnamme fan links nei rjochts en tawize elk part oan syn taak. As de tokens skieden binne, feroaret de fraach fan «past myn sertifikaat by dh none» nei «stiet myn server in suite ta wêrfan't de kaai-útwikseling gjin DH-bestân nedich hat».

Wat dh none eins útskeakelet

dh none seit tsjin de server dat er gjin einich-fjild DH-parameterbestân lade moat. It skeakelet autentikaasje, sertifikaatfalidaasje of TLS sels net út. Wat it wol easket, is dat de ôfpraat kaai-útwikseling ien is dy't dy parameters net nedich hat, wat yn 'e praktyk in ECDHE-suite of in TLS 1.3-hântekening betsjut.

Dêr't it brek komt, is by dy eask. As it TLS-siferbelied fan de server beheind is ta DHE-suites, of as in kliïnt allinnich dy oanbiedt, lit it fuortheljen fan it parameterbestân gjin brûkbere kaai-útwikselingsmetoade oer en mislearret de hântekening. De flater ferskynt meast by de hântekening fan it kontrôlekanaal, foarôfgeand oan alle brûkersautentikaasje. Lês de siferlist eardat jo it ûntbrekkende bestân de skuld jouwe.

Oan 'e kant fan 'e elliptyske kromme wurdt de kromme keazen troch de TLS-konfiguraasje fan 'e server, en OpenVPN biedt in opsje om dy op âldere tûken te kiezen. TLS 1.3 hannelet de groepsûnderhanneling binnen it protokol en rieplachtet hielendal net it DH-bestân.

dh none is op himsels gjin feiligensferleging. De sterkte fan 'e útwikseling hinget dan ôf fan 'e kromme en suite dy't echt ôfpraat wurde, dêrom is de folgjende stap om te sjen wat de pearen keazen hawwe ynstee fan it ûntbrekkende bestân.

De ûnderhanneling befêstigje foar it bewurkjen

Fergees de detaillearringsgraad fan server en kliïnt en lês de rigel fan it kontrôlekanaal dy't OpenVPN nei in ferbining printsjet. Dy neamt de TLS-ferzje en it ôfpraat sifer, en rapportearret it kaaitype fan it sertifikaat fan 'e oare partij. Dy iene rigel beantwurdet de fraach dy't it konfiguraasjebestân allinnich suggerearret.

As it TLS 1.2 mei in ECDHE-RSA-suite en in RSA-sertifikaat sjen lit, is de kombinaasje krekt wat dh none ferwachtet, en is der neat te reparearjen. As it in DHE-suite of in hântekeningmislearring sûnder mienskiplik sifer sjen lit, sit de oplossing yn it siferbelied of de kliïntmooglikheden, net yn it sertifikaat.

Test de âldste kliïnt dy't jo stypje wolle, om't in aktuele kliïnt TLS 1.3 ôfprate kin wylst in âldere beheind is ta TLS 1.2-suites. As de âldste kliïnt gjin oerlap hat, wreidzje dan de tastiene suites út of upgrade dat einpunt.

Skeakelje sertifikaatferifikaasje net út om in hântekeningmislearring foarby te kommen. De mislearring fertelt jo dat de pearen it net iens wurde koenen oer in kaai-útwikseling, en it útskeakeljen fan 'e kontrôle hellet de identiteitsgarânsje fuort sûnder de ôfspraak op te lossen.

Kontrôlelijst: is it sertifikaat RSA, is in ECDHE-suite tastien, lit it log dy suite sjen, en ûnderhannelet de âldste stipe kliïnt dy ek? As alle fjouwer ja binne, docht dh none syn wurk.