Əl sıxma zamanı açıq açar mübadiləsi dəyərinin daşınması, müştərinin daxil olması ilə eyni hadisə deyil. Biri bağlantı üçün kriptoqrafik vəziyyət yaradır; digəri müştərinin kim olduğunu bildirir və yalnız server bunu tələb etdikdə və mübadilə buna imkan verdikdə baş verir. Birincini ikinci kimi qəbul etmək, VPN-in nəyi gizlədib nəyi gizlətmədiyi barədə səhv nəticələrə gətirir. Mesajları oxuyun, sonra dörd xassədən hansını həqiqətən müşahidə etdiyinizi müəyyənləşdirin.

Şəbəkə qeydində eyni görünən iki obyekt

TLS 1.3 müştərisi heç bir sertifikat təqdim etmədən ilk uçuşunda açar mübadiləsi materialı verə bilər. Bu töhfə dizaynca açıqdır, çünki serverə ümumi sirri çıxarmaq üçün lazımdır. Müştəri sertifikatı başqa mesajdır və yalnız server onu tələb etdikdən sonra göndərilir. O, serverin sonra yoxladığı şəxsiyyəti daşıyır və qarşılıqlı autentifikasiya şifr dəstinin tələb etdiyi xassə deyil, serverin verdiyi qərardır. Tətbiq şəxsiyyəti tamamilə üçüncü şeydir: giriş forması, bearer token və ya kuki. Bunların heç biri əl sıxmada görünmür və hamısı şəbəkə yolunun dəyişməsinə tab gətirir.

Object in playWhat it establishes
Key-exchange shareCryptographic state for this connection
Server certificateWhich server the client reached
Client certificateClient authentication, when requested
Application sessionAccount identity inside the application

Dörd sıra bir-birindən asılı deyil. Bağlantıda birinci və ikinci sıra ola bilər, üçüncü sıra buraxıla bilər və dördüncü sıra yenə kuki başlığında daşına bilər.

Tutulmuş əl sıxmanın nəyi sübut edə biləcəyini müəyyənləşdirin

Yalnız əl sıxmadan müşahidəçi razılaşdırılmış versiyanı, şifr dəstini, serverin sertifikatını və açıq açar mübadiləsi dəyərlərini öyrənir. Bu, müştəri tətbiqinin barmaq izini çıxarmaq və hansı serverə qoşulduğunu görmək üçün kifayətdir. Vermədiyi şey, bağlantını deşifrə etmək üçün lazım olan məxfi vəziyyətdir; onun məxfiliyi açıq paya deyil, müvəqqəti mübadiləyə əsaslanır. O, həm də hesab şəxsiyyətini vermir, çünki bu, başlanğıcdan əl sıxmada yox idi.

Deməli, dürüst nəticə dardır: bu mübadilədə heç bir müştəri sertifikatı təqdim edilmədi. Məsələ müştərinin əlaqələndirilə bilən heç nə göndərməməsi deyil və əlbəttə, sessiyanın heç bir identifikator daşımaması da deyil.

Şifr adını deyil, mesajları oxuyun

Şifr dəstindən nəticə çıxarmaq əvəzinə serverdən nə tələb etdiyini soruşun. Sertifikat tələbi olan TLS 1.3 əl sıxması transkriptdə görünür və onun olmaması da eyni dərəcədə görünür.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Sonra müştəri sertifikatı quraşdırılmış halda təkrarlayın və müqayisə edin. İkinci işə salma sertifikatın göndərildiyini və qəbul edildiyini göstərməlidir; birincisi heç nə göstərməməlidir və mübahisənin konkret fərqi budur.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Yalnız adi brauzer halı lazımdırsa, ətraflı müştəri çıxışı protokol versiyasını, yoxlama nəticəsini və müştəri sertifikatının təklif edilib-edilmədiyini görmək üçün kifayətdir. Heç vaxt sertifikat tələbi göndərməyən server onu almış ola bilməz.

Bərpa cavabı harada dəyişir

TLS 1.3 bərpası məxfi vəziyyətlə əlaqəli biletlərdən istifadə edir, buna görə sonrakı bağlantı tam sertifikat mübadiləsi olmadan tamamlana bilər. Bu, müşahidəçinin gördüklərini azaldır və transkriptin sübut etdiyini dəyişir. O, olmayan yerdə şəxsiyyət yaratmır. Bərpa olunmuş sessiya yenə eyni tətbiq sessiyasına aiddir və həmin sessiyadakı hər hansı kuki və ya token vacib identifikator olaraq qalır.

Buna görə "müştəri sertifikatı yoxdur" deyə dayanan məxfilik nəzərdən keçirməsi maraqlı hissəni qaçırır. Sual verməli olan şey, bir əl sıxmadan hansı mesajın çatışmadığı deyil, hansı tərəfin sabit identifikator saxladığıdır.

Bir hökm deyil, dörd xassə qeyd edin

Açar razılaşmasını, server yoxlamasını, müştəri autentifikasiyasını və tətbiq şəxsiyyətini hər biri üçün sübutla birlikdə dörd ayrı sətir kimi yazın. Bu inventar protokol versiyası dəyişdikdə də qalır və məxfiliklə bağlı arqumenti başqası üçün yoxlanıla bilən edir. Sonra şəbəkə yolunun nə verdiyini əlavə edin. VPN xidmətin gördüyü mənbə ünvanını dəyişir; o, tətbiqin artıq saxladığı girişi, kukini və ya cihaz barmaq izini silmir.

Bağlantının razılaşdırılmış versiyasını və sertifikat tələbinin nəticəsini birlikdə qeyd edin, çünki rəyçinin öz qeydi olmadan nəticənizi təkrar etmək üçün lazım olan cüt budur.

Əlaqəli məqalələr