HTTP vs HTTPS-проксиВсё сводится к тому, что видит прокси

Большинство руководств по теме «HTTP против HTTPS-прокси» молчаливо исходят из того, что HTTPS, это обновление: тот же продукт, но с замочком. Выберите HTTPS, и ваш трафик зашифрован, скрапер безопаснее, аккаунт сложнее идентифицировать по отпечатку. Эта формулировка неверна, и следование ей приводит людей к покупке не того продукта по не тем причинам.

HTTP-прокси и HTTPS-прокси, не два качественных уровня одного продукта. Они описывают, какую часть вашего трафика прокси может читать. HTTP-прокси видит ваши запросы в открытом виде: он может их проверять, кэшировать, переписывать заголовки и маршрутизировать по URL. Для HTTPS-сайта тот же прокси открывает непрозрачный туннель и пересылает байты, которые не может расшифровать. Шифрование, которое вас интересует, исходит вовсе не от прокси.

Поэтому настоящий вопрос не «какой прокси более безопасен». Вопрос в другом: нужен ли вам прокси, который проверяет и обрабатывает веб-трафик, или только ретранслирует зашифрованный трафик вслепую? Когда вы формулируете вопрос именно так, выбор перестаёт быть выбором ярлыка и становится вопросом видимости. Остальная часть этого материала развеивает миф и даёт вам единственный решающий вопрос.

HTTP vs HTTPS-прокси: краткая версия

Это вся история в трёх строках. HTTPS, не более безопасный прокси; это тот же прокси, который больше не может видеть ваш трафик.

Миф: HTTPS-прокси, это просто безопасная версия HTTP-прокси

Замочек в браузере, это сквозное шифрование между вами и веб-сайтом, согласованное с помощью TLS (Transport Layer Security, преемник SSL). HTTPS, это просто HTTP, переносимый внутри этой TLS-сессии. Принципиально важно, что это шифрование является свойством соединения между вашим клиентом и сервером, а не функцией какого-либо прокси посередине.

Вот что упускает история про «обновление». Когда вы запрашиваете HTTPS-страницу через обычный HTTP-прокси, ваш трафик по-прежнему зашифрован сквозным образом. Прокси не расшифровывает его, не ослабляет и ничего к нему не добавляет. Он просто пересылает зашифрованные байты. Вам не нужен специальный «HTTPS-прокси», чтобы HTTPS оставался безопасным, потому что безопасность никогда не была задачей прокси.

То, что люди называют «HTTPS-прокси», обычно означает одну из двух несвязанных вещей: прокси, к которому вы подключаетесь через зашифрованное соединение (хоп между вами и прокси защищён TLS), или перехватывающий прокси, который завершает TLS для чтения вашего трафика и повторно шифрует его для отправки на сервер. Это противоположные цели. Один добавляет конфиденциальность на первом хопе; другой намеренно устраняет её, чтобы прокси мог проверять отправляемое вами. Объединение обоих под названием «безопасная версия HTTP-прокси» и поддерживает миф.

Реальная ось: может ли прокси видеть ваш трафик?

Уберите маркетинг, и одна переменная решает всё: может ли прокси читать байты, которые он переносит. Прокси, это один слой косвенности между вами и сервером, и единственный интересный вопрос об этом слое, насколько глубоко он понимает ваш разговор.

HTTP-прокси понимает HTTP. Он читает строку запроса и заголовки, поэтому может кэшировать ответ, удалять или добавлять заголовок, фильтровать по URL, журналировать запросы и применять политики. Эта видимость и есть смысл HTTP-прокси: он является специалистом, способным умно работать с вебом именно потому, что может его читать.

Для HTTPS-назначений эта видимость исчезает по замыслу. Прокси не может читать внутри TLS-сессии, которую он не завершил. Поэтому для переноса HTTPS HTTP-прокси меняет роль: перестаёт быть читателем и становится слепым ретранслятором. Механизм, который его переключает, метод CONNECT, понимание которого снимает всю путаницу между HTTP и HTTPS.

Как CONNECT превращает HTTP-прокси в слепой туннель

Это фрагмент, который почти каждое объяснение пропускает, и именно он делает тему понятной. Стандартный HTTP-прокси переносит ваш HTTPS-трафик, никогда не расшифровывая его, с помощью специального запроса CONNECT. Последовательность короткая:

1. Ваш клиент открывает обычное соединение с прокси и отправляет CONNECT example.com:443. Это единственная часть, которую прокси читает: хост назначения и порт, ничего больше.
2. Прокси открывает TCP-соединение с example.com на порту 443 и, если это удаётся, отвечает 200 Connection Established.
3. С этого момента прокси прекращает парсинг. Он становится трубой, переправляющей сырые байты в обоих направлениях без их интерпретации.
4. Ваш клиент выполняет TLS-рукопожатие непосредственно с example.com через эту трубу. Зашифрованная сессия, между вами и сервером.
5. Все ваши HTTP-запросы и ответы сайта идут внутри этого TLS-туннеля. Прокси видит только зашифрованный текст, который не может читать.

Вот и весь трюк. Обычный HTTP-прокси уже переносит HTTPS, и делает это вслепую. Прокси знает, что вы подключились к example.com:443, и знает, сколько байт прошло, но не может прочитать ни одного запроса, заголовка или куки внутри туннеля. Сквозной TLS между вами и сайтом именно и не даёт прокси это делать.

Из этого прямо вытекают два следствия. Во-первых, для HTTPS прокси не может кэшировать или перезаписывать ничего, поскольку кэширование и перезапись требуют чтения контента, а он не может. Во-вторых, ваш HTTPS-трафик остаётся столь же закрытым от прокси, как и от любого другого на пути. Прокси сводится к TCP-ретранслятору, это та же работа, которую SOCKS5-прокси выполняет для любого протокола.

Что же такое «HTTPS-прокси» на самом деле?

Учитывая, что HTTP-прокси уже туннелирует HTTPS, термин «HTTPS-прокси» делает размытую работу. Сведите его к одному из трёх точных значений:

1. Прокси, к которому вы подключаетесь через TLS

Здесь шифрование находится на первом хопе: соединение от вашего клиента к прокси само обёрнуто в TLS, поэтому тот, кто наблюдает за вашей локальной сетью, видит только зашифрованную ссылку на прокси. Прокси по-прежнему использует CONNECT для достижения HTTPS-сайтов за собой. Это действительно полезно во враждебных сетях, поскольку скрывает, на какие сайты вы туннелируете, от локального наблюдателя, но это конфиденциальность на участке клиент-прокси, а не другой класс прокси.

2. Перехватывающий (завершающий TLS) прокси

Это противоположный замысел. Прокси завершает ваш TLS, расшифровывает трафик, читает или изменяет его, затем повторно шифрует для отправки на сервер. Чтобы сделать это без предупреждений клиента, он должен предъявить сертификат, которому клиент доверяет, поэтому корпоративные сети устанавливают пользовательский корневой сертификат на управляемые устройства. Это именно та позиция «человека посередине», которую TLS призван предотвращать. Это законно для компании, инспектирующей собственный исходящий трафик на собственных машинах, и является красным флагом в любом другом месте.

3. Просторечное обозначение «прокси, работающего с HTTPS-сайтами»

Чаще всего «HTTPS-прокси» означает просто обычный HTTP-прокси, поддерживающий CONNECT, что сегодня свойственно практически всем. Отдельного продукта для покупки не существует. Если поставщик перечисляет «HTTP-прокси» и «HTTPS-прокси» как два уровня, спросите, в чём разница: в протоколе на первом хопе или в чистом маркетинге. Как правило, последнее.

HTTP-прокси vs обработка HTTPS с первого взгляда

Читайте таблицу как одно утверждение, а не двенадцать ячеек: как только трафик становится HTTPS, каждый «умный» столбец сворачивается до «нет», потому что прокси больше не может видеть. Это не ограничение худшего продукта. Это шифрование, работающее так, как задумано.

Что это означает для веб-скрапинга

Если вы занимаетесь скрапингом, почти каждая цель использует HTTPS, поэтому почти каждый запрос через прокси является CONNECT-туннелем. Из этого следует важное уточнение: способность прокси читать ваш трафик не имеет для вас значения, поскольку он всё равно не может его читать. По-настоящему важна та часть, которую прокси всё ещё контролирует: исходящий IP и то, как запрос достигает сервера.

Именно поэтому зацикленность на «HTTP против HTTPS-прокси» является отвлечением при скрапинге. Протокол в названии ничего не говорит о том, будете ли вы заблокированы. Это решает репутация IP, его ротация и то, выглядит ли запрос как запрос из реального браузера, это вопрос датацентра против резидентного, а не HTTP против HTTPS. Прокси, не способный видеть ваш зашифрованный трафик, всё равно может стать разницей между 200 и 403, исключительно через то, с какого IP он выходит.

Также полезно разделять направление и видимость. То, читает ли прокси ваш трафик, это отдельная ось от того, стоит ли он перед вами или перед сервером, что является различием между прямым и обратным прокси. Прокси для скрапинга является прямым прокси, и поведение CONNECT, описанное выше, применяется к нему одинаково независимо от ярлыка протокола в приобретённом тарифе.

Есть одна реальная оговорка безопасности. Поскольку перехватывающий прокси может находиться на пути CONNECT и предъявлять собственный сертификат, никогда не направляйте скрапинг или любой конфиденциальный трафик через бесплатный или неизвестный «HTTPS-прокси», требующий доверять пользовательскому удостоверяющему центру. Сквозной TLS защищает вас только при условии, что никто посередине его не завершил. Надёжный поставщик туннелирует ваш HTTPS через CONNECT и никогда не просит установить корневой сертификат.

CONNECT на практике

Самый чистый способ усвоить всё это, наблюдать за запросом по обоим путям. Направьте инструмент командной строки через HTTP-прокси и запросите HTTPS-страницу: клиент выдаёт CONNECT, прокси ретранслирует туннель, и ваше TLS-рукопожатие происходит с сервером, а не с прокси.

# Plain HTTP: the proxy reads the full request
# and could cache, log, or rewrite it.
curl -x "http://user:[email protected]:8080" \
     "http://example.com/page"

# HTTPS: same proxy, but -v shows it send
# CONNECT first, then a blind TLS tunnel.
curl -v -x "http://user:[email protected]:8080" \
     "https://example.com/page"

В подробном выводе второй команды вы увидите строку вроде CONNECT example.com:443, за которой следует 200 Connection Established, и только затем TLS-рукопожатие. То, что это рукопожатие идёт к серверу, а не к прокси, является наглядным доказательством того, что ваш HTTPS является сквозным. Прокси переместил ваши байты, ни разу их не прочитав.

Если вы хотите, чтобы прокси управлял исходящим IP, а не просто ретранслировал, та же CONNECT-механика применяется, только управляемая конечная точка берёт на себя ротацию и повторные попытки. Это разница между одним статичным хопом и пулированной конечной точкой, та же идея, что и в API-прокси, фронтирующем множество выходов под одним адресом.

Часто задаваемые вопросы

Является ли HTTPS-прокси более безопасным, чем HTTP-прокси?

Не по своей природе. Шифрование, защищающее HTTPS-сайт, это сквозной TLS между вами и сервером, и обычный HTTP-прокси сохраняет его, туннелируя трафик через CONNECT. «HTTPS-прокси» обычно означает либо то, что хоп до прокси зашифрован, либо то, что прокси перехватывает ваш TLS, что является противоположностью более безопасного.

Может ли HTTP-прокси обрабатывать HTTPS-трафик?

Да, и почти все они это делают. Когда вы запрашиваете HTTPS URL, ваш клиент отправляет прокси команду CONNECT с хостом и портом назначения. Прокси открывает TCP-соединение, а затем слепо ретранслирует зашифрованные байты. Он никогда не расшифровывает трафик; ваша TLS-сессия находится с веб-сайтом, а не с прокси.

Что такое метод CONNECT?

CONNECT, это HTTP-запрос, который просит прокси открыть необработанный TCP-туннель к назначению вместо загрузки ресурса. Клиент отправляет CONNECT host:port, прокси устанавливает соединение и отвечает 200, и с этого момента пересылает байты без их парсинга. Именно так HTTP-прокси переносят HTTPS, SSH и другие туннелированные протоколы.

Расшифровывает ли прокси мой HTTPS-трафик?

Обычный прокси, нет. С CONNECT он видит только хост назначения и зашифрованный поток байт. Исключение составляет перехватывающий прокси, который завершает TLS и предъявляет собственный сертификат, что позволяет ему читать ваш трафик, но требует, чтобы ваше устройство доверяло его удостоверяющему центру. Если прокси просит вас установить корневой сертификат, он может читать всё, что вы отправляете.

Какой прокси использовать для веб-скрапинга?

При скрапинге ярлык HTTP против HTTPS едва ли важен, поскольку почти все цели используют HTTPS и туннелируются через CONNECT независимо от этого. Важна репутация исходящего IP и его ротация. Выбирайте, исходя из соотношения датацентра и резидентного и того, выполняет ли прокси ротацию и повторные попытки, а не из названия протокола.

В чём разница между HTTP-прокси и SOCKS5-прокси?

HTTP-прокси понимает веб-трафик и может кэшировать, перезаписывать и фильтровать открытый HTTP, туннелируя HTTPS вслепую через CONNECT. SOCKS5-прокси ничего не понимает о протоколе, который переносит; он ретранслирует необработанный TCP или UDP для любого приложения. Конкретно для HTTPS оба в итоге пересылают непрозрачный зашифрованный поток.

BA

Bilal Ahmed

Инженер-программист · Crawlbase

Инженер-программист, написавший некоторые из самых читаемых материалов в блоге Crawlbase о веб-скрейпинге, прокси и инструментах для работы с данными.