TLS idarə kanalının içində gedir, bütün tunelin içində yox

VPN təsvirində TLS sözünü görüb veb-proksinin bu trafiki anlayacağı qənaətinə gəlmək geniş yayılmış qısayoldur. Bu protokolun içində tərəflər öz paketlərini mübadilə edir və TLS həmin mübadilənin bir kanalının hissəsi kimi işləyir. İstifadəçini maraqlandıran faydalı yük fərqli mesaj formatında gedir, buna görə də ikisi heç vaxt adi HTTPS sessiyası ilə üst-üstə düşmür.

Zərf birinci gəlir

Hər tunel paketi protokolun öz başlığı ilə başlayır: mesaj növü, açar identifikatoru və bayt axını nəqlində paketin harada bitdiyini göstərən uzunluq prefiksi. Bu zərfi təhlil etməyən oxucu növbəti sahənin haradan başladığını bilə bilməz.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Bu eskiz bayt cədvəli deyil, xəritədir, çünki dəqiq sahələr mesaj növündən asılıdır, halbuki birinci oktet həmişə əməliyyat kodunu və açar identifikatorunu birlikdə yığır. Mesaj növünü port nömrəsindən təxmin etmək dekoderlərin gördüklərini səhv adlandırmasına səbəb olur. Diaqnoz üçün vacib olan sıradır: nəql, sonra protokol zərfi, sonra iki iş növündən biri. Ondan sonra gələnlər barədə fikir yürütməzdən əvvəl zərfi oxuyun. Səhv yerdən başlayan dekoder inamlı cəfəngiyyat hasil edir.

Etibarlılıq qatı protokola aiddir

İdarə mesajları sıralı, təsdiqlənmiş çatdırılma tələb edir və protokol bunu özü təsdiqlər və yenidən göndərmələrlə təmin edir. Təsdiq ayrıca mesaj kimi gələ bilər və ya başqa idarə mesajı ilə birlikdə gedə bilər, bu da bir təmiz mübadilə gözləyənlər üçün izləri qeyri-müntəzəm göstərir.

Fayda odur ki, TLS əl sıxma xarici nəql UDP olsa belə etibarlı daşıyıcı alır. Qiymət odur ki, tək datagram həmin söhbətin yalnız bir hissəsini ehtiva edə bilər, buna görə də onu müstəqil TLS qeydi kimi qəbul etmək cəfəngiyyat doğurur. Yenidən yığım protokol qatında baş verməlidir. Buna görə də tutulmuş paket nadir hallarda tam əl sıxma addımı kimi görünür.

Xarici nəqli TCP-yə keçirmək bu qatı aradan qaldırmır. Etibarlı nəql protokol səviyyəsində daha az yenidən göndərmə deməkdir, çərçivələmənin yoxa çıxması və ya trafikin HTTP-yə çevrilməsi deyil.

Məlumat paketləri fərqli formatdan istifadə edir

Sessiya yarandıqdan sonra faydalı yük daxili IP paketləri və ya Ethernet çərçivələri daşıyan məlumat mesajları kimi gəlir. Onlar öz açarları və öz emalı ilə qorunur və heç bir TLS kitabxanasının qəbul edəcəyi mənada TLS tətbiq qeydləri deyillər.

Bu ayrılıq konfiqurasiyada görünür: idarə kanalı və məlumat kanalı ayrı şifrə parametrlərinə malikdir, buna görə də birini adlandıran log sətri digəri haqqında sizə heç nə demir. Güclü idarə şifrəsini güclü məlumat şifrəsinin sübutu kimi oxumaq geniş yayılmış hesabat səhvidir.

Oxşar bir yanlış təsəvvürü də izahdan kənarda saxlayın. TLS simmetrik məlumat kanalının yanında oturan açıq açar kanalı deyil, çünki TLS açarlar qurulduqdan sonra öz qeydlərini simmetrik qoruyur. Əsl fərq rol və paket formatıdır, hər tərəfin hansı kriptoqrafiyadan istifadə etməsi deyil.

Niyə HTTPS proksisi kömək edə bilməz

TLS-i sonlandıran proksi TLS qeyd axını və onun içində tətbiq protokolu gözləyir. Bu protokolun idarə kanalı öz çərçivələməsinin içində, ətrafında etibarlılıq qatı ilə daşınır, buna görə də sonlandıran proksi bu çərçivələməni zədəli giriş kimi oxuyur.

Baytları və ya datagramları şərh etmədən ötürən şəffaf yönləndirici işləyə bilər, bir şərtlə ki, axını yenidən yazmasın və ya yenidən yığmasın. Hər hansı vasitəçi barədə veriləcək sual budur: o, faktiki nəqli və çərçivələməni ötürürmü, yoxsa haradasa TLS-i dəstəkləyirmi. Proksi qaydalarına bir axşam sərf etməzdən əvvəl bunu soruşun. Buradakı uğursuzluqların çoxu çatışmayan parametr deyil, arxitekturadır.

İzi düzgün oxumaq

Əvvəlcə idarə mübadiləsi, sonra daha çox sayda məlumat mesajı gözləyin, hər ikisi bir nəqldən istifadə edir. İdarə mərhələsi tamamlanır və məlumat mərhələsi dayanırsa, nasazlıq əl sıxma ilə deyil, açarlar, marşrutlaşdırma və ya məlumat yolunun filtrlənməsi ilə bağlıdır. Bir neçə məlumat mesajı tutun və onların ümumiyyətlə müştəridən çıxıb-çıxmadığını yoxlayın. Bu tək müşahidə axtarışı yarıya bölür.

Tarixi açar-metod təsvirləri protokol sənədlərində müəyyən bir buraxılışın hələ də hər köhnə formatı dəstəklədiyini ifadə etmir. İşlətdiyiniz versiyanı yoxlayın, sonra işlərin əvvəllər necə getdiyini təsvir edən paraqrafa əsaslanaraq gözlənti qurun.