HTTPS-proksi iki TLS bağlantısı deməkdir, bir yox

HTTPS-proksi etiketi yalnız müştərinizlə proksi arasındakı nəqli təsvir edir, başqa heç nəyi yox. O, arxasındakı veb-saytın həmin bağlantı ilə şifrələndiyini demir və proksinin səhifəni oxuya bildiyini də demir. İki bağlantını ayırdıqdan sonra sertifikat xətaları sirli olmaqdan çıxır və VPN ilə müqayisə konkretləşir.

İki son nöqtə cütü, iki yoxlama

Adi tunel rejimində iki TLS münasibəti var. Birincisi müştərinizdən proksiyə gedir və proksini autentifikasiya edir. İkincisi müştərinizdən tunelin içindəki veb-sayta gedir və veb-saytı autentifikasiya edir. Onlar bir-birindən asılı olmayaraq uğursuz olur və asılı olmayaraq konfiqurasiya edilir.

Onların ayrı etimad qərarları, ayrı sertifikat zəncirləri və ayrı uğursuzluq mesajları var. Təşkilati CA istifadə edən proksi ilə açıq zəncir istifadə edən ictimai veb-sayt qanuni olaraq fərqli yoxlama konfiqurasiyasına ehtiyac duya bilər və bu, səhv konfiqurasiya deyil.

Onlara eyni soketi paylaşan iki bağlantı kimi baxın, çünki əslində elədir.

CONNECT əslində nəyi tunelləyir

Müştəri host və portu göstərən CONNECT sorğusu göndərir, proksi isə həmin hədəfə TCP bağlantısı açır. Proksi cavab verdikdən sonra ardınca gələn baytlar heç bir şərh olmadan ötürülür, buna görə veb-saytın TLS əl sıxması proksidən toxunulmadan keçir. Beləliklə proksi təyinat adını və bağlantı metadatasını öyrənir, lakin bu quruluşdan şifrəsi açılmış səhifələr almır.

Bu fərq tunel rejiminin bütün təhlükəsizlik arqumentidir və həm də onun həddidir.

Proksi keçidində TLS olmayan HTTP-proksi yenə də CONNECT vasitəsilə HTTPS veb-saytını daşıyır. Müştəri ilə proksi arasındakı mübadilə açıq qalır, veb-sayt bağlantısı isə yox, və bütün bunu HTTPS-proksi adlandırmaq bu fərqi gizlədir.

Hansı sertifikat uğursuz oldu

Yoxlama uğursuz olduqda, hər hansı etimad parametrini dəyişməzdən əvvəl xətada göstərilən son nöqtəni oxuyun. İki uğursuzluq terminalda oxşar görünür və tamamilə fərqli düzəlişlərə işarə edir, buna görə ilk sual həmişə hansı bağlantının imtina etdiyidir.

curl seçimləri məhz bu səbəbdən ayırır. Proksi CA faylı proksinin yoxlanmasını tənzimləyir, CA faylı isə serverin yoxlanmasını tənzimləyir və tətbiq olunan etimad anbarının davranışı da curl-un necə qurulduğundan asılıdır.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Yoxlamanı boğmaq təmir deyil. O, iki son nöqtədən heç biri haqqında heç nə sübut etmir.

Yoxlama fərqli bir quruluşdur

TLS yoxlaması tunelləmə deyil. Yoxlayan vasitəçi veb-sayta baxan etimad münasibətini sonlandırır və müştəriyə öz sertifikatını təqdim edir, buna görə müştəri saytı deyil, vasitəçini yoxlayır. Bu, təsdiqlənmiş dizayn çərçivəsində qanuni ola bilər və bayt-bayt ötürmədən maddi cəhətdən fərqli bir iddiadır. Hər proksinin yoxladığını güman etməyin və şifrələnmiş proksi keçidinin bunu istisna etdiyini də güman etməyin.

Etimad anbarınızdakı təşkilati CA hansı quruluşda olduğunuza dair bir işarədir, sübut deyil. Dizaynı sertifikat zəncirindən çıxarmaq əvəzinə soruşun.

Bu iki quruluş səhifəni kimin oxuya bilməsi sualına fərqli cavablar verir.

Proksi ilə VPN-i eyni dörd sətirdə müqayisə edin

Müqayisə yalnız hər iki yerləşdirmə eyni şəkildə təsvir olunduqda faydalı olur.

Bir sorğu üçün konfiqurasiya edilmiş proksi yalnız o sorğunu əhatə edir. O, cihazdakı hər prosesi özündən keçirmir və nümunə əmr məhz bu qədər dardır. VPN-in əhatəsi onun marşrutlaşdırmasından və tətbiq siyasətindən asılıdır, bunlar da güman edilmək əvəzinə yoxlanmalıdır. Heç bir variant sadəcə quraşdırıldığı üçün hər şeyi əhatə etmir.

Hər variant üçün dörd sətri yazın və mübahisə adətən özü həll olunur. Faydalı müqayisə hansı etiketin daha şifrəli səslənməsi deyil. Hansı seqmentlərin qorunduğu, onların uclarında kimin yoxlandığı, hansı vasitəçilərə etimad etdiyiniz və siyasətin həqiqətən hansı trafiki əhatə etdiyidir.