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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Проверьте www.bluecoat.com является коммерческим прокси, который на самом деле МОЖЕТ сделать перехват https для блокировки сайтов, ограничения контента, проверки на наличие вирусов и кеша (GET)

Answer 4

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

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

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

Тело данных / сообщений на стороне сервера будет предварительно зашифровано и кэшировано в распределенной хэш-таблице в памяти. Шифрование не будет выполняться для каждого отдельного запроса.

Я также исследую использование шины сообщений, такой как NServiceBus.

Answer 5

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

Answer 6

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

Я думаю о чем-то вроде этого:

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