Je, cheti cha RSA kinaweza kufanya kazi na dh none katika OpenVPN?

Hapa kuna mpangilio wa seva unaosema dh none kando ya cheti kinachosema RSA, pamoja na shaka inayosumbua kwamba moja wapo lazima iwe mbaya. Hakuna kilicho mbaya. Cheti huti saini na kuthibitisha; kubadilishana funguo huweka siri ya pamoja. Hizi ni kazi mbili tofauti katika handshake moja, na TLS huruhusu cheti cha RSA kuthibitisha handshake inayotumia makubaliano ya muda mfupi kwenye mkunjo wa mviringo.

Machafuko kawaida huja na mwongozo wa uhamiaji. Unasema badilisha faili ya vigezo vya DH na dh none, msomaji anagundua kuwa cheti si cheti cha mkunjo wa mviringo, na ukweli huo wawili huchukuliwa kama mgongano.

Kwa nini mipangilio miwili inaonekana kuhusiana

Mpangilio wa zamani wa OpenVPN ulihitaji faili ya vigezo vya DH kwa sababu Diffie-Hellman wa uwanja wenye kikomo unahitaji vigezo vya kikoa ambavyo pande zote zinakubaliana. Agizo dh lilionyesha faili hilo. Wakati utekelezaji unahamia ECDH, vigezo vinatoka kwenye mkunjo wenye jina badala yake, na faili haihitajiki tena, jambo ambalo dh none linaeleza.

Vyeti ni mhimili tofauti. Hubeba ufunguo wa umma na sahihi zinazothibitisha utambulisho wa seva, na ufunguo huo unaweza kuwa RSA au mkunjo wa mviringo bila kujali jinsi ufunguo wa kikao unakubaliwa. Handshake inayotumia ECDHE kwa makubaliano ya ufunguo na RSA kwa uthibitishaji ni ya kawaida na imesambazwa kwa upana.

Uteuzi wa majina huongeza mwingiliano. Mkunjo wa mviringo unaonekana katika majina ya suite za ECDHE na ECDSA, kwa hiyo ni rahisi kudhani kwamba muunganisho wowote unaotaja mkunjo lazima uwe na cheti cha mkunjo. Sivyo.

Jinsi ya kusoma jina la suite ya TLS 1.2 kwa usahihi

Chukua ECDHE-RSA-AES256-GCM-SHA384. Token ya kwanza ni familia ya kubadilishana funguo: Diffie-Hellman wa muda mfupi kwenye mkunjo wa mviringo. Ya pili ni familia ya uthibitishaji: RSA. Sehemu iliyobaki inaeleza ulinzi wa rekodi na hashi inayotumika katika handshake.

Suite ya ECDHE-ECDSA inatumia familia hiyo hiyo ya kubadilishana funguo na mbinu tofauti ya uthibitishaji, kwa hiyo inahitaji cheti cha mkunjo wa mviringo. Suite ya DHE-RSA inatumia Diffie-Hellman wa muda mfupi wa uwanja wenye kikomo na uthibitishaji wa RSA, na hiyo inahitaji vigezo vya DH kwa kweli.

Soma jina la suite kutoka kushoto kwenda kulia na gawa kila sehemu kwa kazi yake. Baada ya token kutenganishwa, swali hubadilika kutoka «je, cheti changu kinalingana na dh none» hadi «je, seva yangu inaruhusu suite ambayo kubadilishana funguo kwake hakuhitaji faili ya DH».

dh none inazima nini kwa kweli

dh none inaiambia seva isipakie faili ya vigezo vya DH ya uwanja wenye kikomo. Haizimi uthibitishaji, uthibitisho wa vyeti au TLS yenyewe. Hata hivyo inahitaji kwamba kubadilishana funguo kulikokubaliwa hakuhitaji vigezo hivyo, ambayo kwa vitendo inamaanisha suite ya ECDHE au handshake ya TLS 1.3.

Kutokana na hitaji hilo ndipo kuvunjika hutokea. Ikiwa sera ya sifa za TLS ya seva imezuiwa kwa suite za DHE, au mteja anatoa hizo tu, kuondoa faili ya vigezo hakuachi njia yoyote ya kubadilishana funguo inayoweza kutumika na handshake inashindwa. Hitilafu kawaida huonekana wakati wa handshake ya channel ya udhibiti, kabla ya uthibitishaji wowote wa mtumiaji. Soma orodha ya sifa kabla ya kulaumu faili iliyokosekana.

Kwa upande wa mkunjo wa mviringo, mkunjo huchaguliwa na mpangilio wa TLS wa seva, na OpenVPN inatoa chaguo la kuuchagua kwenye matawi ya zamani. TLS 1.3 hushughulikia mazungumzo ya kikundi ndani ya itifaki na haiitaji faili ya DH hata kidogo.

dh none yenyewe si kupungua kwa usalama. Nguvu ya kubadilishana basi inategemea mkunjo na suite zilizokubaliwa kwa kweli, ndiyo sababu hatua inayofuata ni kuangalia kile pande zilichagua na si faili iliyokosekana.

Kuthibitisha mazungumzo kabla ya kuhariri

Ongeza kiwango cha maelezo cha seva na mteja na soma mstari wa channel ya udhibiti ambao OpenVPN huchapisha baada ya muunganisho. Unataja toleo la TLS na sifa iliyokubaliwa, na unaripoti aina ya ufunguo wa cheti cha mwenzako. Mstari huo mmoja unajibu swali ambalo faili ya mpangilio inaonyesha kidokezo tu.

Ikiwa inaonyesha TLS 1.2 na suite ya ECDHE-RSA na cheti cha RSA, mchanganyiko huo ni hasa kile dh none inatarajia, na hakuna cha kurekebisha. Ikiwa inaonyesha suite ya DHE au kushindwa kwa handshake bila sifa ya pamoja, marekebisho yako katika sera ya sifa au uwezo wa mteja, si katika cheti.

Jaribu mteja wa zamani zaidi unaokusudia kumuunga mkono, kwa sababu mteja wa sasa anaweza kukubaliana na TLS 1.3 wakati wa zamani amezuiwa kwa suite za TLS 1.2. Ikiwa mteja wa zamani zaidi hana mwingiliano wowote, ama panua suite zinazoruhusiwa au boresha kituo hicho cha mwisho.

Usizime uthibitisho wa vyeti ili kuepuka kushindwa kwa handshake. Kushindwa kunakuambia kwamba pande hazikuweza kukubaliana kuhusu kubadilishana funguo, na kuzima ukaguzi kunaondoa dhamana ya utambulisho bila kutatua makubaliano.

Orodha ya ukaguzi: je, cheti ni RSA, je, suite ya ECDHE inaruhusiwa, je, kumbukumbu inaonyesha suite hiyo, na je, mteja wa zamani zaidi anayeungwa mkono naye anakubaliana nayo? Ikiwa zote nne ni ndiyo, dh none inafanya kazi yake.