RSA sertifikatı OpenVPN-də dh none ilə işləyə bilərmi?

Budur, RSA yazan sertifikatın yanında dh none yazan bir server konfiqurasiyası, üstəlik onlardan birinin mütləq səhv olduğuna dair narahat bir şübhə. Heç nə səhv deyil. Sertifikat imzalayır və autentifikasiya edir; açar mübadiləsi ortaq sirr yaradır. Bunlar eyni əl sıxışmada iki fərqli işdir və TLS RSA sertifikatına efemer elliptik əyri razılaşması istifadə edən əl sıxışmasını autentifikasiya etməyə imkan verir.

Qarışıqlıq adətən miqrasiya təlimatı ilə gəlir. O, DH parametr faylını dh none ilə əvəz etməyi deyir, oxucu sertifikatın elliptik əyri sertifikatı olmadığını görür və iki fakt ziddiyyət kimi qəbul edilir.

Niyə iki parametr əlaqəli görünür

OpenVPN-in köhnə konfiqurasiyası DH parametr faylı tələb edirdi, çünki sonlu sahə Diffie-Hellman hər iki tərəfin razılaşdığı domen parametrlərinə ehtiyac duyur. dh direktivi həmin fayla işarə edirdi. Yerləşdirmə ECDH-ə keçdikdə parametrlər əvəzinə adlı əyridən gəlir və fayl artıq lazım olmur; dh none məhz bunu ifadə edir.

Sertifikatlar ayrı bir oxdur. Onlar serverin kimliyini sübut edən açıq açar və imza daşıyır və bu açar sessiya açarının necə razılaşdırılmasından asılı olmayaraq RSA və ya elliptik əyri ola bilər. Açar razılaşması üçün ECDHE, autentifikasiya üçün RSA istifadə edən əl sıxışması adi və geniş yayılmışdır.

Adlandırma üst-üstə düşməni daha da pisləşdirir. Elliptik əyri həm ECDHE, həm də ECDSA paket adlarında görünür, ona görə əyridən bəhs edən hər hansı bağlantının əyri sertifikatı ehtiva etməli olduğunu düşünmək asandır. Elə deyil.

TLS 1.2 paket adını düzgün oxumaq

ECDHE-RSA-AES256-GCM-SHA384 götürün. Birinci token açar mübadiləsi ailəsidir: efemer elliptik əyri Diffie-Hellman. İkincisi autentifikasiya ailəsidir: RSA. Qalan hissə qeyd qorunmasını və əl sıxışmada istifadə olunan heşi təsvir edir.

ECDHE-ECDSA paketi eyni açar mübadiləsi ailəsini fərqli autentifikasiya üsulu ilə istifadə edir, ona görə elliptik əyri sertifikatı tələb edir. DHE-RSA paketi RSA autentifikasiyası ilə sonlu sahə efemer Diffie-Hellman istifadə edir və o, həqiqətən DH parametrləri tələb edir.

Paket adını soldan sağa oxuyun və hər hissəni öz işinə aid edin. Tokenlər ayrıldıqdan sonra sual «sertifikatım dh none ilə uyğundurmu» sorusundan «serverim açar mübadiləsi DH faylı tələb etməyən paketə icazə verirmi» sualına çevrilir.

dh none əslində nəyi söndürür

dh none serverə sonlu sahə DH parametr faylını yükləməməyi tapşırır. O, autentifikasiyanı, sertifikat yoxlamasını və ya TLS-in özünü söndürmür. Tələb etdiyi odur ki, razılaşdırılmış açar mübadiləsi həmin parametrlərə ehtiyac duymasın; praktikada bu, ECDHE paketi və ya TLS 1.3 əl sıxışması deməkdir.

Qırılma məhz bu tələbdən gəlir. Əgər serverin TLS şifr siyasəti DHE paketləri ilə məhdudlaşırsa və ya müştəri yalnız onları təklif edirsə, parametr faylının çıxarılması istifadəyə yararlı açar mübadiləsi üsulu qoymur və əl sıxışması uğursuz olur. Xəta adətən idarə kanalı əl sıxışması zamanı, istifadəçi autentifikasiyasından əvvəl görünür. Çatışmayan faylı günahlandırmadan əvvəl şifr siyahısını oxuyun.

Elliptik əyri tərəfində əyri serverin TLS konfiqurasiyası tərəfindən seçilir və OpenVPN köhnə budaqlarda onu seçmək üçün seçim təqdim edir. TLS 1.3 qrup razılaşmasını protokolun içində həll edir və DH faylına heç müraciət etmir.

dh none özlüyündə təhlükəsizlik səviyyəsinin aşağı salınması deyil. Mübadilənin gücü sonra faktiki razılaşdırılan əyri və paketdən asılıdır; buna görə növbəti addım olmayan fayla deyil, tərəflərin nə seçdiyinə baxmaqdır.

Redaktə etməzdən əvvəl razılaşmanı təsdiqləmək

Serverin və müştərinin ətraflılıq səviyyəsini artırın və OpenVPN-in bağlantıdan sonra çap etdiyi idarə kanalı sətrini oxuyun. O, TLS versiyasını və razılaşdırılmış şifri adlandırır və qarşı tərəfin sertifikatının açar növünü bildirir. Həmin tək sətir konfiqurasiya faylının yalnız ima etdiyi suala cavab verir.

Əgər o, TLS 1.2 ilə ECDHE-RSA paketi və RSA sertifikatı göstərirsə, kombinasiya dh none-un gözlədiyi kimidir və düzəldiləsi heç nə yoxdur. Əgər DHE paketi və ya ortaq şifr olmadan əl sıxışması uğursuzluğu göstərirsə, düzəliş sertifikatda deyil, şifr siyasətində və ya müştəri imkanlarındadır.

Dəstəkləmək istədiyiniz ən köhnə müştərini sınayın, çünki cari müştəri TLS 1.3 razılaşdıra bilər, köhnəsi isə TLS 1.2 paketləri ilə məhdudlaşır. Ən köhnə müştərinin üst-üstə düşməsi yoxdursa, ya icazə verilən paketləri genişləndirin, ya da həmin son nöqtəni yeniləyin.

Əl sıxışması uğursuzluğunu keçmək üçün sertifikat yoxlamasını söndürməyin. Uğursuzluq tərəflərin açar mübadiləsi barədə razılaşa bilmədiyini bildirir və yoxlamanın söndürülməsi razılaşmanı həll etmədən kimlik zəmanətini aradan qaldırır.

Yoxlama siyahısı: sertifikat RSA-dır, ECDHE paketinə icazə verilir, jurnal həmin paketi göstərir və ən köhnə dəstəklənən müştəri də onu razılaşdırırmı? Dördü də «bəli»dirsə, dh none öz işini görür.