DH faylı, yoxsa tls-auth açarı? İki OpenVPN faylını ayırd etmək

İki fayl, iki direktiv və hər ikisini konfiqurasiya etdikləri şeyin adı ilə adlandırma vərdişi. dh.pem beləcə tls-auth sətrinə düşür və klient gözlənilməz açar formatı barədə mesajla uğursuz olur. Qarşındakı qərar hansı faylın daha güclü olması deyil. Hansı rolun yerləşdirməyə həqiqətən lazım olduğudur və üç şərt bunu həll edir: TLS yığının hansı açar mübadiləsini razılaşdıracaq, idarəetmə kanalı autentifikasiyasını ümumiyyətlə istəyirsənmi və materialın gizli qalması lazımdırmı.

Bunları sıra ilə cavablandır, fayl sualı özü cavab tapacaq. Onları atlarsan, direktiv adları bir-birini əvəz edən görünməyə başlayır və səhvin gəldiyi vəziyyət elə budur.

Fayl adından əvvəl etiketi oxu

Faylın ilk sətri adından daha çox məlumat verir, çünki ad insan konvensiyasıdır, etiket isə alət tərəfindən istehsal olunur. Diffie-Hellman parametrləri BEGIN DH PARAMETERS PEM etiketini daşıyır. OpenVPN statik açarı isə tamamilə fərqli bir quruluşdur, öz başlığı və hex yükü var.

ta.key adlanan parametr faylı yenə parametrlərdir, dh.pem adlanan statik açar isə yenə statik açardır; adı dəyişmək heç nəyi çevirmir, parser məzmunu oxuyur və uyğunsuzluğu rədd edir. Profili redaktə etməzdən əvvəl yoxla:

head -n 1 dh.pem
head -n 1 ta.key

Hansı faylın lazım olduğunu müəyyən edən üç şərt

Birinci şərt mübadilədir. Sonlu sahəli Diffie-Hellman əl sıxışması qrup tələb edir və dh direktivi serverin bunun üçün parametrləri adlandırdığı yerdir. Elliptik əyri əl sıxışmasına o fayl qətiyyən lazım deyil, çünki əyri parametr çoxluğudur. Serverin yalnız ECDHE dəstlərini razılaşdırırsa, DH faylı əlavə güc deyil, ölü yükdür.

İkinci şərt idarəetmə kanalı autentifikasiyasıdır və öz materialı olan ayrı funksiyadır. tls-auth faylı hər iki tərəfin saxladığı paylaşılan statik açardır, idarəetmə kanalı paketlərini imzalamaq üçün istifadə olunur ki, autentifikasiya olunmamış tərəf əl sıxışmasını tamamlaya bilməsin. Sonlu sahəli DH istifadə edib-etməməyindən asılı olmayaraq mövcuddur və qrup parametrləri ilə əlaqəsi yoxdur.

Üçüncü şərt gizlilik və paylamadır. DH parametrləri sessiyanı zəiflətmədən yayımlana bilər, çünki gizli dəyərlər hər əl sıxışması üçün yaradılır və tərəfləri heç vaxt tərk etmir. Statik açar yayımlanmamalıdır: hər iki tərəfdə eyni baytlardır, özü fırlanmır və onu saxlayan hər kəs etibarlı idarəetmə kanalı imzaları yarada bilər. Bu iki cavab tamamilə fərqli rəftar qaydalarına işarə edir, buna görə bir fayl repozitoriyada qala bilər, digəri isə yox.

Hər rol üçün düzgün material yarat

Direktivin gözlədiyi formatı istehsal edən alətdən istifadə et, onlar arasında çevirmə. OpenVPN 2.6-da paylaşılan açar üçün generatorun tipli forması məqsədi açıq şəkildə göstərir.

openvpn --genkey tls-auth ta.key

Bu əmr yeni gizli material yaradır; mövcud açarı təmir etmir və ya yoxlamır, yenidən işə salmaq isə digər tərəflərdə olmayan fərqli açar verir. Yaranan faylı ehtiyacı olan tərəflərə hər hansı paylaşılan sirr üçün istifadə edəcəyin kanalla köçür və istiqamət konvensiyasını ardıcıl saxla: tls-auth ilə bir tərəf key-direction 0, digəri key-direction 1 istifadə edir.

DH parametrləri lazım olduqda açar generatorundan deyil, parametr yaradılmasından gəlir və nəticə açıq olsa da mənşəyi vacibdir. Naməlum mənbədən götürülmüş qrup açıq olduğuna görə etibarlı olmur; o, hələ də tərəflərin razılaşdığı və ölçüsü ya quruluşu ilə zəiflədilməyən qrup olmalıdır.

dh none nə edir və nə etmir

dh none dar mənalı real direktivdir: sonlu sahəli parametr faylı yüklənməyəcək, çünki əl sıxışması elliptik əyri Diffie-Hellman istifadə edir. O, nəyisə zəiflətmək mənasında “DH addımını atla” üçün qısa yol deyil və heç bir halda OpenVPN-ə başqa faylı əvəz kimi qəbul etməyi tapşırmır.

Səhv oxumaqdan iki səhv çıxır. Birincisi, dh none-in tls-auth ehtiyacını aradan qaldırdığını güman etməkdir, halbuki ikisi fərqli şeyləri idarə edir. İkincisi, yalnız əyri konfiqurasiyasının yanında köhnə dh sətrini saxlayıb sonra serverin əslində hansı faylı istifadə etdiyini düşünməkdir; direktiv varsa, fayl oxunur və oradakı pozulmuş yol razılaşdırılacaq mübadilə ilə əlaqəsiz səbəbdən işə salmanı uğursuz edir.

Yanlış fayl artıq yerləşdirilibsə

Nəzərdə tutulan sirri profil sahibindən bərpa et və bunu edərkən sertifikat yoxlamasına toxunma. Uğursuzluq etimad uğursuzluğu deyil, format uyğunsuzluğudur və yoxlamanı söndürüb xətanı keçmək işə salma problemini səssiz problemlə əvəz edir.

Sonra insanların birləşdirməyə meylli olduğu iki hadisəni ayır. DH parametr faylını yayımlamaq demək olar ki, zərərsizdir, çünki parametrlər dizaynca açıq idi. tls-auth açarını ifşa etmək isə başqa hadisədir: açar onu saxlayan hər tərəf üçün idarəetmə kanalı paketlərini autentifikasiya edir, buna görə dəyişdirmə bir hosta deyil, bütün yerləşdirmə boyu əlaqələndirilməlidir.

Beş dəqiqəlik yoxlama hansı halda olduğunu həll edir: hər faylın ilk sətrini oxu, ona istinad edən direktivi təsdiqlə və faylın paylanmasının materialın tələblərinə uyğun olduğunu təsdiqlə. Bu, işlək PKI-ni yenidən yaratmaqdan kiçik bir işdir və üç şərtin bütün müddət işarə etdiyi də elə budur.