HTTPS прокси означава две 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 по същите четири реда

Сравнението става полезно само когато и двете внедрявания са описани по един и същ начин.

Прокси, конфигурирано за една заявка, покрива тази заявка. То не прекарва всеки процес на устройството през себе си и примерната команда е точно толкова тесна. Покритието на VPN зависи от неговото маршрутизиране и политика за приложенията, които също трябва да се проверят, а не да се предполагат. Нито една от двете опции не покрива всичко само защото е инсталирана.

Запишете четирите реда за всяка опция и спорът обикновено се решава сам. Полезното сравнение не е коя етикет звучи по-криптирано. А кои сегменти са защитени, кой е проверен в краищата им, на кои посредници имате доверие и какъв трафик политиката всъщност обхваща.