Назад | Перейти на главную страницу

Есть ли способ кэшировать HTTPS-запросы на прокси-сервере?

Мы используем прокси-сервер Squid в нашей среде и хотим кэшировать HTTPS-запросы.

Есть ли способ настроить Squid или вообще прокси-сервер для кеширования HTTPS-запросов?

Есть способ сделать это, но он в корне противоречит причинам использования HTTPS.

Вот как бы вы это сделали.

  1. Создайте самоподписанный сертификат SSL для сайта, запросы с которого вы хотите перехватывать и кэшировать.
  2. Установите и запустите stunnel на своем прокси-сервере, сообщив ему, что сертификат, который он должен предоставить, является тем, который был создан на этапе 1.
  3. Попросите stunnel пересылать расшифрованные запросы в squid.
  4. Возможно, вам понадобится stunnel на другой стороне или openssl_client, чтобы повторно зашифровать запрос к вышестоящему серверу.

Предостережения:

  1. Ваши пользователи будут вас ненавидеть. Каждый запрос SSL к этому сайту будет отображать окно неверного сертификата.
  2. Вы подвергаете себя потенциальным судебным искам за непослушные поступки. (IANAL)
  3. Вы сможете получить только самозаверяющий сертификат, работающий для этого, из-за того, как должна работать сеть доверия PKI для SSL-сертификатов. Ничего не говоря о скомпрометированных корневых центрах сертификации.

Я не собираюсь подробно рассказывать, как это сделать, потому что а) Я считаю это несколько неэтичным, и б) Тебе лучше научиться это делать.

Я предлагаю вам изучить, как работают оглушающие атаки и атаки «злоумышленник в середине».

Просто чтобы объяснить, почему это невозможно сделать без MITM - прокси-сервер видит только DNS-имя сервера, к которому вы хотите подключиться, при использовании зашифрованного HTTPS. Он не видит ни URL-адреса, ни заголовков ответов. Он не может определить, к какому отдельному ресурсу вы обращаетесь на сайте, кэшируется он или нет, а также время его модификации. Все, что он может видеть, это то, что кто-то что-то хочет от удаленного сервера, использующего HTTPS.

Это означает, что кеширование не может работать, поскольку прокси-сервер не знает, какие кэшированные объекты предоставить вам или как их получить в первую очередь.

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

Zeus (теперь Riverbed) ZTM Traffic Manager может это сделать, поскольку он может транслировать трафик http и https в обе стороны и кэшировать незашифрованный контент - он работает, мы его используем, но это ужасающе дорого - как в цене Porsche за сервер.