Может ли (|| любой) прокси-сервер кэшировать контент, который запрашивается клиентом через https? Поскольку прокси-сервер не может видеть строку запроса или заголовки http, я считаю, что они не могут.
Я рассматриваю настольное приложение, управляемое несколькими людьми за прокси своих компаний. Это приложение может получать доступ к службам через Интернет, и я хотел бы воспользоваться встроенной инфраструктурой интернет-кэширования для «чтения». Если кэширующие прокси-серверы не могут кешировать содержимое, доставленное по протоколу SSL, будет ли приемлемым вариантом просто шифрование содержимого ответа?
Я рассматриваю все запросы GET, которые мы хотим, чтобы их можно было кэшировать, запрашивать через http, зашифровывая тело с использованием асимметричного шифрования, где у каждого клиента есть ключ дешифрования. Каждый раз, когда мы хотим выполнить GET, который не кэшируется, или операцию POST, он будет выполняться через SSL.
Нет, напрямую кешировать https невозможно. Вся связь между клиентом и сервером зашифрована. Прокси-сервер расположен между сервером и клиентом, для его кэширования необходимо иметь возможность прочитать его, то есть расшифровать шифрование.
Вы можете сделать что-нибудь для кеширования. Вы в основном делаете SSL на своем прокси, перехватывая SSL, отправленный клиенту. В основном данные зашифрованы между клиентом и вашим прокси, они расшифрованы, прочитаны и кэшированы, а данные зашифрованы и отправлены на сервер. Ответ с сервера также расшифровывается, читается и шифруется. Я не уверен, как вы делаете это на основных прокси-программ (например, Squid), но это возможно.
Единственная проблема с этим подходом состоит в том, что прокси должен будет использовать самоподписанный сертификат для шифрования его клиенту. Клиент сможет сказать, что прокси в середине прочитал данные, так как сертификат не будет с исходного сайта.
Комментарий Рори о том, что прокси-сервер должен будет использовать самоподписанный сертификат, если не является строго верным.
Прокси-сервер может быть реализован так, чтобы генерировать новый сертификат для каждого нового хоста SSL, с которым его просят работать, и подписывать его общим корневым сертификатом. В сценарии OP корпоративной среды общий сертификат подписи довольно легко можно установить в качестве доверенного ЦС на клиентских машинах, и они с радостью примут эти «поддельные» сертификаты SSL для проксируемого трафика, поскольку не будет несоответствия имени хоста.
Фактически именно так программное обеспечение, такое как Charles Web Debugging Proxy, позволяет проверять трафик SSL, не вызывая ошибок безопасности в браузере и т. Д.
Я думаю, что вы должны просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая выполняет кеширование (например, WinInet в Windows). Трудно представить, что преимущества корпоративного кэширования стоят того, чтобы написать собственную схему шифрования безопасности или получить удовольствие от сертификатов на прокси. Хуже того, в схеме шифрования, которую вы упоминаете, асимметричные шифры в теле сущности звучат как огромный удар по серверной части вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.
Я думаю, что вы должны просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая выполняет кеширование (например, WinInet в Windows). Трудно представить, что преимущества корпоративного кэширования стоят того, чтобы написать собственную схему шифрования безопасности или получить удовольствие от сертификатов на прокси. Хуже того, на схеме шифрования, которую вы упоминаете, выполнение асинметричных шифров на теле сущности звучит как огромный удар по серверной части вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.
Речь идет не о браузере, а о настольном приложении, которое передает данные через Интернет. То, что должно произойти, это то, что все экземпляры приложения будут тянуть одну и ту же часть примерно в одно и то же время. Эти данные должны быть защищены, но я надеюсь увеличить производительность, если некоторые экземпляры приложения получат кэшированную версию с корпоративного прокси-сервера.
Куски данных небольшие, но их можно часто запрашивать. По сути, все экземпляры приложений будут запрашивать одни и те же данные одновременно.
Тело данных / сообщений на стороне сервера будет предварительно зашифровано и кэшировано в распределенной хэш-таблице в памяти. Шифрование не будет выполняться отдельно для каждого запроса.
Я также исследую использование шины сообщений, такой как NServiceBus.
Проверьте www.bluecoat.com является коммерческим прокси, который на самом деле МОЖЕТ сделать перехват https для блокировки сайтов, ограничения контента, проверки на вирусы и кеширования контента (GET)
Как насчет настройки кэша сервера на сервере приложений за компонентом, который шифрует ответы https? Это может быть полезно, если у вас есть обратный прокси-сервер.
Я думаю о чем-то вроде этого:
application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)