Заставить cURL использовать GET на прокси для HTTP-запросов
Я пытаюсь использовать прямой прокси-сервер (Apache Traffic Server или Squid) на моей локальной машине в качестве локального HTTP-кэша для моих вызовов cURL.
Я настроил прокси используя:
curl_setopt($ch, CURLOPT_PROXY, 'http://localhost:8080');
Когда я запрашиваю сайт HTTP, cURL выполняет стандартный HTTP GET запрос прокси, который может быть правильно кэширован:
GET http://example.com/ HTTP/1.1
Однако при запросе веб-сайта HTTP, cURL выполняет CONNECT вместо этого, эффективно используя прокси-сервер в качестве TCP-туннеля и не позволяя ему кэшировать ответ:
CONNECT example.com:80 HTTP/1.1
Есть ли способ заставить CURL выполнить GET запросить даже для HTTP-сайтов?
Я могу понять причину использования туннеля TCP для запросов HTTP через прокси-сервер HTTP для безопасности, но поскольку мой прокси-сервер находится на локальном хосте, мне все равно, использовать небезопасное соединение HTTP с прокси-сервером, и я хотел бы, чтобы cURL выполнил GET запрос:
GET https://example.com/ HTTP/1.1
Я пытался с помощью:
curl_setopt($ch, CURLOPT_HTTPPROXYTUNNEL, false);
Но это ничего не изменило.
Решение
Я не верю, что это можно сделать, используя некоторые общие настройки конфигурации на стороне клиента, как было бы отрицать всю цель HTTPS (что никто не может подслушивать ваш HTTPS-трафик).
Таким образом, вы можете настроить свой прокси для создания атака «человек посередине» расшифровать HTTPS-трафик, проходящий через него. Squid proxy должен поддерживать это, используя свои Функция «Удар SSL». Для этого есть хорошее вступление эта вики и больше настроить документы здесь.
В этом режиме squid делает то, что получает адрес удаленного сервера от клиента CONNECT запрос и вместо создания просто слепого туннеля к серверу, он запускает новый прямой HTTPS-запрос на сервер и сохраняет ответ. Таким образом, Squid имеет доступ ко всему трафику и может кешировать его или делать все, что Squid может с ним делать.
При отправке ответов обратно клиенту он сам должен представить сертификат HTTPS (клиент ожидает трафик HTTPS), поэтому в Squid есть функция для автоматически генерировать сертификаты для всех прокси доменов. Для его настройки вам необходимо создать локальный центр сертификации. Обратите внимание, что эти автоматически генерируемые сертификаты будут простыми самозаверяющими сертификатами, поэтому на стороне клиента это будет выглядеть как ненадежные сертификаты и вам нужно будет отключить проверку сверстников (CURLOPT_SSL_VERIFYPEER = false).
Я не смог найти подобную функцию на сервере трафика Apache. Кажется, они поддерживают только Прекращение SSL в режиме обратного прокси.
Последнее замечание: пожалуйста, имейте в виду, что это все же скорее взлом, и расшифровка HTTPS может привести к юридическим или этическим проблемам. Никогда не делайте этого без согласия клиентов!
Другие решения
Я не думаю, что другие ответы здесь понимают, что вы хотите сделать. Но это возможно.
Вы хотите сделать запрос https и выполнить его следующим образом:
client <--http--> cache <--https--> remote server
Таким образом, вы небезопасно отправляете запрос https через http в вашей локальной сети, в локальный кеш, а затем кеш надежно извлекает его как https через открытый интернет.
Для этого нужно просто взломать первый прыжок. Ваша клиентская программа делает простой http-запрос в кэш, но добавляет заголовок, который говорит, что преобразовать в https при следующем переходе, например:
x-use-protocol: https
Придумайте любой заголовок, который вам нравится. Чтобы это работало, и клиент, и кэш должны понимать этот заголовок, чтобы преобразование происходило. Это не хорошо для общего просмотра веб-страниц — или в любое время, когда вы не можете контролировать клиента. Но это хороший ответ, если вы пишете и клиент, и кеш.