OpenVPN nəzarət paketlərinin izlənməsi: TLS-dən əvvəl tls-auth

tls-auth xətası adətən əl sıxışması problemi kimi bildirilir, halbuki heç vaxt belə olmamışdır. HMAC hər hansı TLS emalı başlamazdan əvvəl nəzarət paketində yoxlanılır, buna görə uyğun olmayan açar və ya istiqamət sertifikat problemini xatırladan və iki qat əvvəl həll olunan xəta yaradır. Zərfi ayrı obyekt kimi qəbul etmək diaqnozu qısaldır: sahələri oxuyun, yoxlamanın erkən işə düşdüyünü təsdiqləyin, sonra hər iki tərəfin razılaşmalı olduğu üç şeyi müqayisə edin.

Zərfi qurulduğu sıra ilə oxuyun

Nəzarət paketi sessiya identifikatoru, istəyə bağlı tls-auth HMAC-ı, replay və təsdiq məlumatı və etibarlı mesaj identifikatoru daşıyır, ondan sonra mesaj tipi yükü gəlir. Mesaj əl sıxışması mesajı olduqda, yük TLS şifrəli mətni olur. Bütün əlaqə bundan ibarətdir: TLS materialı zərfin artıq qoruduğu mesajın içində gedir. Bax OpenVPN şəbəkə protokolu arayışı nəzarət kanalı sahələrini həmin sıra ilə sadalayır.

Etibarlılıq qatını kriptoqrafiya ilə səhv salmaq asandır. Təsdiqlər, yenidən göndərmə və mesaj identifikatoru nəzarət mesajlarının etibarsız nəqliyyat üzərində bir dəfə və sıra ilə çatması üçün mövcuddur. Onlar autentifikasiya deyil və düzgün mesaj identifikatoru paketi kimin göndərdiyini sübut etmir.

Bu qruplaşdırmanı konseptual saxlayın. O, bayt sırası diaqramı deyil və teq hesablamaq üçün kifayət etmir, çünki HMAC-a daxil olan sahələr tətbiqdən, versiyadan və rejimdən asılıdır.

Yoxlamanın əl sıxışmasından əvvəl işə düşdüyünü göstərin

Ortaq açarı olan qəbuledici HMAC-ı yoxlaya və saxta paketi dərhal ata bilər, əl sıxışması vəziyyəti ayırmadan və açıq açar işi görmədən. Müdafiə ilkin əl sıxışması paketlərini də əhatə edir, buna görə səhv açar gec autentifikasiya xətası kimi deyil, uğursuz bağlantı kimi görünür.

Demonun sözlülüyünü artırın və tun cihazı yerinə nəzarət kanalını izləyin:

openvpn --config /etc/openvpn/server.conf --verb 6

Axtardığınız şey paket səviyyəsində, hər hansı TLS xəbərdarlığından əvvəl bildirilən nəzarət kanalı HMAC yoxlama xətasıdır. Jurnalda TLS xəbərdarlığı zərfin qəbul edildiyini və xətanın içəriyə keçdiyini bildirir; bu, fərqli düzəlişi olan fərqli bir araşdırmadır.

İstiqamət idarəsi də buradadır. Statik açar faylı tls-auth ilə istifadə edildikdə, iki tərəf əks açar istiqamətləri götürür və protokol bu bölgüdən istifadə edir ki, tutulmuş paket göndərənə geri qaytarıla bilməsin. İstiqaməti tərsinə çevirmək açarı eyni saxlayır və yenə də hər paketi uğursuz edir. Bir dəfə bir tərəfi dəyişin, sonra cütün birlikdə yüklənməsi üçün hər iki demonu yenidən başladın.

Hər iki tərəfdə açarı, istiqaməti və digest-i uyğunlaşdırın

Üç dəyər razılaşmalıdır və yalnız biri fayldır. Statik açar məzmunu hər iki tərəfdə eyni olmalı, istiqamət əks olmalı və HMAC üçün istifadə olunan digest uyğun olmalıdır. Açar materialına toxunmazdan əvvəl konfiqurasiyanı yoxlayın, çünki bir tərs istiqamət korlanmış fayldan daha çox uğursuzluğu izah edir:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Ortaq sirri redaktordan deyil, alətdən yaradın və icazələrini sıx saxlayın:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Köhnə buraxılışlar açar yaradılması üçün bir qədər fərqli seçim sırası qəbul edirdi və həmin buraxılışlar üçün yazılmış profillər hələ də dövriyyədədir. Yaradılan fayl hər iki halda eyni növ obyektdir, buna görə yoxlama onun hansı yazılışla yaradıldığı deyil, hər iki tərəfin eyni baytları saxlamasıdır.

tls-auth ilə tls-crypt-i qarışdırmayın. Hər ikisi nəzarət kanalını qoruyur, lakin tls-crypt onu həm də şifrələyir və əl sıxışmasını müşahidəçilərdən gizlədir, və istiqamət bölgüsünü öz açar idarəsi ilə əvəz edir. Birini istifadə edən profil digəri üçün konfiqurasiya edilmiş həmyaşıdla işləməyəcək və heç bir digest tənzimləməsi bu boşluğu bağlamır.

Teqi yalnız real formatdan bərpa edin

Bayt dəqiqliyində bərpa VPN işlətməkdən ayrı bir vəzifədir və yalnız real girişlərlə işləyir: paketi quran tətbiq və versiya, seçilmiş digest, istiqamət və sessiya identifikatoru ilə təsdiq massivi daxil olmaqla faktiki baytlar. Sahə siyahısının mətn təqdimatı həmin baytlar deyil.

Teq uzunluğu digest-dən irəli gəlir, buna görə sabit uzunluq fərziyyəsi kimsə onu dəyişdiyi anda pozulur. Paketi tətbiqin etdiyi kimi heşləyin, bloq yazısındakı cədvəlin təqdim etdiyi kimi deyil, və əl ilə çıxardığınız gözlənti ilə deyil, eyni həmyaşıddan götürülmüş tutma ilə müqayisə edin.

Bu məşği istehsal profillərindən uzaq saxlayın. Teqin bərpası barədə heç nə sizə bir yerləşdirmənin müdafiəni aktivləşdirməli olub-olmadığını demir.

Müdafiəni götürmədən uyğunsuzluğu geri qaytarın

Cazibədar sınaq tls-auth-u silmək, bağlantının uğurlu olduğunu görmək və açarın səhv olduğu qənaətinə gəlməkdir. Bu cavab sizə müdafiəyə başa gəlir və üç dəyərdən hansının uyğunsuz olduğunu öyrətmir. Bunun əvəzinə server tərəfindən təsdiqlənmiş uyğun konfiqurasiyanı götürün və onunla müqayisə edin.

Dəyişikliyi geri qaytarıla bilən şəkildə hazırlayın. Əvvəlki server konfiqurasiyasını və açar faylını saxlayın, düzəldilmiş cütü tətbiq edin, bir müştərinin əl sıxışmasını tamamladığını yoxlayın və yalnız bundan sonra ehtiyat nüsxəni silin. Dəyişiklikdən sonra müştərilər uğursuz olarsa, kəsinti zamanı üçüncü variant uydurmaq əvəzinə əvvəlki faylları bərpa edin. Bərpa başlamazdan əvvəl artıq bildiyiniz bir əmr olmalıdır.

Nəhayət, keçmiş yoxlamanın nə demək olduğunu xatırlayın. O, həmyaşıdın ortaq açarı saxladığını sübut edir, sertifikatının və ya hesabının səlahiyyətli olduğunu deyil, və razılaşdırılmış məlumat kanalı şifrinə dair heç nə demir. Avtorizasiya və məlumat müdafiəsi sonra qurulur, buna görə təmiz zərf yoxlaması hökm deyil, başlanğıc nöqtəsidir.