Может ли прокси-сервер кэшировать SSL GET? Если нет, будет ли достаточно шифрования тела ответа?

Может ли (|| любой) прокси-сервер кэшировать содержимое, запрашиваемое клиентом по https? Поскольку прокси-сервер не может видеть строку запроса или заголовки http, я думаю, они не могут.

Я подумываю о настольном приложении, которым будет управлять несколько человек, стоящих за прокси-сервером своей компании. Это приложение может получать доступ к службам через Интернет, и я хотел бы воспользоваться встроенной инфраструктурой кэширования в Интернете для «чтения». Если кэширующие прокси-серверы не могут кэшировать контент, доставленный по протоколу SSL, будет ли простое шифрование контента ответа приемлемым вариантом?

Я считаю, что все запросы GET, которые мы хотим кэшировать, должны быть запрошены через http с зашифрованным телом с использованием асимметричного шифрования, где у каждого клиента есть ключ дешифрования. Каждый раз, когда мы хотим выполнить GET, который не кэшируется, или операцию POST, она будет выполняться через SSL.

Ответов (4)

Решение

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

Вы можете что-нибудь сделать, чтобы его кешировать. Вы в основном делаете SSL на своем прокси, перехватывая SSL, отправленный клиенту. Обычно данные зашифровываются между клиентом и вашим прокси, они дешифруются, читаются и кэшируются, а данные зашифровываются и отправляются на сервер. Ответ сервера также расшифровывается, читается и зашифровывается. Я не уверен, как это сделать в основных прокси-программах (например, в Squid), но это возможно.

Единственная проблема с этим подходом заключается в том, что прокси-сервер должен будет использовать самоподписанный сертификат для его шифрования для клиента. Клиент сможет сказать, что прокси посередине прочитал данные, поскольку сертификат не будет с исходного сайта.

Комментарий Рори о том, что прокси-сервер должен использовать самозаверяющий сертификат, если не является строго правдой.

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

Фактически, именно так программное обеспечение, такое как Charles Web Debugging Proxy, позволяет проверять трафик SSL, не вызывая ошибок безопасности в браузере и т. Д.

Я думаю, вам следует просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая выполняет кеширование (например, WinInet в Windows). Трудно представить, что преимущества кэширования в масштабе предприятия оправдывают затраты на написание настраиваемой схемы шифрования безопасности или забавы с сертификатом на прокси-сервере. Хуже того, в схеме шифрования, которую вы упомянули, выполнение асимметричных шифров на теле объекта звучит как огромный удар производительности на стороне сервера вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.

Как насчет настройки серверного кеша на сервере приложений за компонентом, который шифрует ответы https? Это может быть полезно, если у вас настроен обратный прокси.

Я думаю примерно так:

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)