Заставить cURL использовать GET для прокси-сервера для запросов HTTP

Question

Я пытаюсь использовать прямой прокси-сервер (Apache Traffic Server или Squid) на своем локальном компьютере в качестве локального кеша HTTP для вызовов cURL.

Я настроил прокси, используя:

curl_setopt($ch, CURLOPT_PROXY, 'http://localhost:8080'); 

Когда я запрашиваю вебсайт HTTP, локон выполняет стандартный HTTP GET запрос прокси, который может быть кэшированные правильно:

GET http://example.com/ HTTP/1.1 

Однако , при запросе веб-сайта HTTPs 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); 

Но это ничего не изменило.

Answer 1

Не думаю, что это может быть сделано с использованием некоторых общих настроек конфигурации на стороне клиента, поскольку отрицает всю цель HTTPS (что никто не сможет подслушать ваш HTTPS-трафик).

Ваш единственный вариант - настроить ваш прокси-сервер, чтобы в основном создать man-in-the-middle attack, чтобы расшифровать трафик HTTPS, проходящий через него. Прокси-сервер Squid должен поддерживать это, используя их "SSL bump" feature. Есть хорошее введение для него на this wiki и более setup docs here.

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

При отправке ответов обратно клиенту он сам должен представить сертификат HTTPS (клиент ожидает HTTPS-трафик), поэтому в Squid есть функция automatically generate certificates для всех проксированных доменов. Чтобы настроить его, вам, по существу, придется создать локальный центр сертификации. Обратите внимание, что эти автоматически сгенерированные сертификаты будут простыми самоподписанными сертификатами, поэтому на стороне клиента это будет выглядеть как ненадежных сертификатов, и вам нужно будет отключить проверку сверстников (CURLOPT_SSL_VERIFYPEER = false).

Я не смог найти подобную функцию на сервере трафика Apache. Кажется, они поддерживают только SSL termination в режиме обратного прокси.

Последнее примечание: учтите, что это все еще скорее хак и дешифрование HTTPS может привести к юридическим или этическим проблемам. Никогда не делайте этого без согласия клиентов!

Answer 2

Я не думаю, что другие ответы здесь понимают, что вы хотите делать. Но это возможно.

Вы хотите сделать запрос по протоколу HTTPS и он закончить, как это:

client <--http--> cache <--https--> remote server 

Так вы отправите запрос на HTTPS небезопасным через HTTP в вашей локальной сети, в локальный кэш, затем извлечь его кэш безопасно, как https через открытый интернет.

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

x-use-protocol: https 

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