HTTPS прокси значи две TLS врски, а не една
Прокси скокот и веб-страницата се одделни TLS односи со одделна доверба. Прочитајте кој крај не успеа пред да смените било какво поставување на сертификат.
Ознаката HTTPS прокси го опишува само преносот помеѓу вашиот клиент и проксито, и ништо повеќе. Таа не вели дека веб-страницата зад него е шифрирана со таа иста врска, ниту пак вели дека проксито може да ја чита страницата. Откако ќе ги разделите двете врски, грешките со сертификати престануваат да бидат мистериозни и споредбата со VPN станува конкретна.
Два пара крајни точки, две проверки
Во обичен тунелски режим има два TLS односа. Првиот оди од вашиот клиент до проксито и го автентицира проксито. Вториот оди од вашиот клиент до веб-страницата внатре во тунелот и ја автентицира веб-страницата. Тие не успеваат независно и се конфигурираат независно.
Тие имаат одделни одлуки за доверба, одделни синџири на сертификати и одделни пораки за грешка. Прокси со организациски CA и јавна веб-страница со јавен синџир можат легитимно да бараат поинаква конфигурација за проверка, и тоа не е погрешна конфигурација.
Третирајте ги како две врски што случајно делат еден сокет, зашто тоа и се.
Што всушност тунелира CONNECT
Клиентот испраќа барање CONNECT со името на домаќинот и портата, а проксито отвора TCP врска до таа цел. Откако проксито ќе одговори, бајтите што следат се пренесуваат без интерпретација, поради што TLS ракувањето на веб-страницата поминува низ проксито недопрено. Така проксито го дознава името на одредиштето и метаподатоците за врската, но не добива дешифрирани страници од тој распоред.
Таа разлика е целиот безбедносен аргумент за тунелскиот режим, и таа е исто така неговата граница.
HTTP прокси без TLS на прокси скокот сѐ уште пренесува HTTPS веб-страница преку CONNECT. Размената клиент-прокси е отворена, додека врската со веб-страницата не е, и нарекувањето на сето тоа HTTPS прокси ја крие таа разлика.
Кој сертификат не успеа
Кога проверката не успее, прочитајте ја крајната точка наведена во грешката пред да смените било какво поставување за доверба. Двете грешки изгледаат слично во терминал и укажуваат на сосема различни поправки, затоа првото прашање е секогаш која врска одби.
curl ги разделува опциите токму поради оваа причина. Датотеката CA на проксито ја конфигурира проверката на проксито, додека датотеката CA ја конфигурира проверката на серверот, а однесувањето на применливото складиште за доверба исто така зависи од тоа како е изграден curl.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Потиснувањето на проверка не е поправка. Тоа не докажува ништо за ниту една од двете крајни точки.
Инспекцијата е поинаков распоред
TLS инспекцијата не е тунелирање. Инспекциски посредник ја завршува врската за доверба кон веб-страницата и му го претставува сопствениот сертификат на клиентот, така што клиентот го проверува посредникот, а не страницата. Тоа може да биде легитимно според одобрен дизајн, и тоа е суштински поинакво тврдење од пренесување бајт по бајт. Немојте да претпоставувате дека секое прокси врши инспекција, и немојте да претпоставувате дека шифриран прокси скок тоа го исклучува.
Организациски CA во вашето складиште за доверба е навестување за тоа во кој распоред сте, а не доказ. Прашајте за дизајнот наместо да го заклучувате од синџир на сертификати.
Тие два распореди даваат различни одговори на прашањето кој може да ја чита страницата.
Споредете прокси и VPN на истите четири линии
Споредбата станува корисна само кога двете распоредувања се опишани на ист начин.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
Прокси конфигурирано за едно барање го покрива тоа барање. Тоа не го поминува секој процес на уредот низ себе, и пример-командата е точно толку тесна. Покриеноста на VPN зависи од неговото рутирање и политиката за апликации, што исто така треба да се провери, а не да се претпостави. Ниту една од двете опции не покрива сѐ само затоа што е инсталирана.
Запишете ги четирите линии за секоја опција и расправата обично се решава сама. Корисната споредба не е која ознака звучи пошифрирано. Туку кои сегменти се заштитени, кој е проверен на нивните краеви, на кои посредници им верувате и кој сообраќај политиката всушност го опфаќа.