Заставить 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

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

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

Ответ 1

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

Таким образом, ваш единственный вариант - настроить свой прокси-сервер для создания атаки man-in-the-middle, чтобы расшифровать трафик HTTPS, проходящий через Это. Прокси-сервер Squid должен поддерживать это, используя функцию "Эффект SSL" . Для него есть приятное введение в эту вики и более установить документы здесь.

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

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

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

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

Ответ 2

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

Вы хотите сделать запрос https и завершить его следующим образом:

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

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

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

x-use-protocol: https

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