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 зависит от его маршрутизации и политики приложений, которые тоже нужно проверять, а не предполагать. Ни один из вариантов не покрывает всё только потому, что был установлен.

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