OpenVPN: EC və ED — adlar niyə güc nərdivanı deyil
EC, ED, ECDHE və auth fərqli suallara cavab verir. Hər hansı bir şeyi müqayisə etməzdən və ya düzəltməzdən əvvəl OpenVPN profilini hər adın gördüyü işə görə sıralayın.
Bir profildə ec, ed, ecdh, ecdsa, auth və bir TLS şifrə siyahısını yan-yana qoyun, fayl altı vəziyyətli güc çarxına bənzəməyə başlayır. Amma deyil. Hər ad fərqli suala cavab verir və onlardan birində fərqlənən iki profil mütləq bir-birindən güclü və ya zəif deyil. Adları yerinə yetirdikləri işə görə sıralamaq təqribən beş dəqiqə çəkir və insanların işlək konfiqurasiyaya etdiyi pis düzəlişlərin çoxunu qabaqlayır.
Aşağıdaki sıralama qarışıqlığın özündən başlayır, sonra trafikinizi həqiqətən nəyin qoruduğunu müəyyən edən profil hissələrinə doğru genişlənir. Hər bölmə növbə ilə bir yanlış oxunuşu götürür və adın əslində nəyə bağlı olduğunu göstərir.
İki hərf, iki fərqli sual
Ən çox mübahisə doğuran cüt EC və ED-dir və mübahisə adətən onların bir suala rəqib cavablar olduğunu fərz edir. Onlar hətta eyni oxda deyil. EC riyaziyyat ailəsini təsvir edir: elliptik əyri kriptoqrafiyası, burada təhlükəsizlik böyük sonlu sahədə deyil, əyri üzərində diskret loqarifmin çətinliyindən gəlir.
ED həmin ailənin içindəki əyri formasını təsvir edir. Twisted Edwards əyriləri sürət və bir neçə tətbiq səhvinə qarşı müqavimət üçün seçilmiş təqdimatdır və Ed25519 insanların adətən nəzərdə tutduğu addır. Əyri elliptik əyri kriptoqrafiyasına rəqib deyil; o, elliptik əyrinin yazılma üsullarından biridir. ED-ni "daha yeni, daha güclü EC" kimi oxumaq ilk səhv dönüşdür və ondan sonrakı hər şey eyni istiqamətdə səhv olmağa meyllidir.
İmzalama və mübadilə ayrı işlərdir
Ailə sualı həll olunduqdan sonra qalan adlar heç vaxt bir-birini əvəz etməyən iki sütuna bölünür. Bir sütun imzalayır, digəri ortaq sirr üzərində razılaşır.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
Həm EdDSA, həm də ECDSA imzalayır, lakin onlar fərqli açar formatları olan fərqli sxemlərdir, ona görə biri üçün verilmiş sertifikat digəri kimi istifadə oluna bilməz. EdDSA kiçik əyri çoxluğu üçün təyin olunub; P-256 onlardan biri deyil, buna görə P-256 sertifikatı ECDSA ilə yoxlanılır və heç vaxt Ed25519 ilə yoxlanılmır.
Mübadilə sütununda EdDH adlanan ekvivalent yoxdur. Curve25519 açarı üzərində efemer razılaşma X25519-dur və bu, P-256-da olduğu kimi, müəyyən əyri ilə ECDH-dir. Ed25519 ciddi şəkildə imza sxemini bildirir, baxmayaraq ki, iki əyri əlaqəli olduğu üçün ad mübadilə üçün sərbəst istifadə olunur: imzalama üçün istifadə olunan Edwards forması və X25519 üçün istifadə olunan Montgomery forması eyni alt qrupu təsvir edir.
Niyə EC profilində dh faylı yoxdur
dh faylı sonlu sahə Diffie-Hellman üçün əvvəlcədən yaradılmış parametrləri ehtiva edir və bu parametrlər ona görə mövcuddur ki, böyük sadə ədəd və generator haradansa gəlməlidir. Elliptik əyri mübadiləsinə onlar lazım deyil: adlanmış əyri parametr çoxluğudur və hər iki tərəf onu artıq bilir. EC profilinə direktivi buraxmağa imkan verən bütün səbəb budur.
Başqa cür müasir görünən profildə iki hal hələ də dh sətri yaradır. Birincisi, həqiqətən sonlu sahə qrupları üzərində danışıqlar aparan ikinci dinləyici və ya daha köhnə həmdir. İkincisi, RSA dövrü şablonundan köçürülmüş və heç vaxt silinməmiş qalıq mətndir. Mübadilə üçün əyri adlandıran və hələ də 2048 bitlik dh faylı yükləyən profil bunu etdiyi üçün daha təhlükəsiz deyil; o, istifadə olunmayan bir artefakt daşıyır.
TLS 1.3 açar mübadiləsini addan çıxardı
TLS_AES_256_GCM_SHA384 ilə TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 sətrini müqayisə edin və qısa ad aşağı salınma kimi görünür. Bu, adın dəyişdirilməsidir və səbəb strukturidir: TLS 1.3 statik RSA və sonlu sahə Diffie-Hellman açar mübadiləsini çıxardı, buna görə efemer elliptik əyri mübadiləsi qalan yeganə qeyri-PSK seçimdir. Onu hər paketdə adlandırmaq eyni faktı on iki dəfə təkrar edərdi.
Sertifikat növü addan əlaqəli səbəbə görə yox oldu. 1.3-də sertifikat əl sıxma imzasını doğrulaşdırır, açar razılaşmasını deyil, ona görə artıq paketi seçmir. Buna görə də konfiqurasiyada 1.3 üçün ayrıca şifrə siyahısı var: paketlər yenidən adlandırıldı və yenidən təşkil olundu, zəiflədilmədi.
Bir nəticəni açıq şəkildə qeyd etməyə dəyər. ECDHE açar mübadiləsi alqoritmidir və heç vaxt şifrə deyil. "Elliptik" kimi təsvir olunan paket iki tərəfin ortaq açara necə gəldiyi haqqında bir şey deyir və bundan sonra yükü nəyin şifrələdiyi haqqında heç nə demir.
auth paketləri doğrulaşdırır, yükləri deyil
auth direktivi paketləri doğrulaşdıran HMAC həzmini seçir və onun tarixi standart dəyəri SHA1-dir. Qeyri-AEAD məlumat şifrəsi ilə OpenVPN həzmi şifrə mətni üzərində hesablayır və ona əlavə edir, bu şifrələ-sonra-MAC quruluşu doldurmanın manipulyasiyasını qeyri-mümkün edən şeydir.
Buradakı mif auth dəyərini SHA512-yə qaldırmağın tuneli möhkəmləndirməsidir. Bu, şifrələmənin gücünü artırmır və razılaşdırılmış məlumat şifrəsi AES-256-GCM kimi AEAD rejimidirsə, həzm ümumiyyətlə məlumat paketlərinə tətbiq olunmur. GCM etiketi onları artıq doğrulaşdırır və auth dəyəri idarə kanalı HMAC-ı və hələ istifadədə olan hər hansı qeyri-AEAD şifrə üçün qalır.
Deməli, direktiv vacibdir, lakin fayldakı mövqeyinin təklif etdiyindən daha dar yerdə vacibdir. Həqiqətən hansı şifrənin razılaşdırıldığını yoxlamaq onun ümumiyyətlə tətbiq olunub-olunmadığını sizə deyir.
Profili rütbəyə görə deyil, sütuna görə oxuyun
Üç sual təbəqələri təmiz ayırır və hər birinə razılaşdırılmış sessiyanın fərqli hissəsi cavab verir. Yükü hansı şifrə qoruyur? Hər paketə hansı etiket və ya həzm zəmanət verir və istifadədə olan şifrə ümumiyyətlə belə bir şey tələb edirmi? Əl sıxmanı kimin sertifikatı bağladı və idarə kanalı əlavə olaraq tls-auth və ya tls-crypt ilə qorunurmu?
EC və ya ED etiketində heç nə o üç sualdan heç birini həll etmir və paket adı tək başına onlardan heç birini də həll etmir. Razılaşdırılmış nəticə yeganə dəlildir, ona görə gücü lüğətdən çıxarmaq əvəzinə onu oxuyun:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logBirinci əmr sertifikatınızın həqiqətən hansı imza sxemindən istifadə etdiyini sizə deyir, bu da ECDSA və ya Ed25519 ilə işlədiyinizi bilməyin yeganə etibarlı yoludur. İkincisi müştərinin sessiya üçün qeydə aldığı idarə kanalı sətrini, o cümlədən TLS versiyasını və üzərində dayandığı paketi göstərir. Əgər profil düzəlişi bu iki çıxışdan biri ilə əsaslandırıla bilmirsə, bu, çox güman ki, xassəyə deyil, ada edilən dəyişiklikdir.