My<cod/>.net
Может ли прокси-сервер кэшировать SSL GETs? Если нет, то будет ли достаточно шифрования тела ответа?
Может ли (||любой) прокси-сервер кэшировать содержимое, запрошенное клиентом через https? Поскольку прокси-сервер не может видеть строку запроса или заголовки http, я думаю, что они не могут.
Я рассматриваю настольное приложение, управляемое рядом людей, стоящих за своими компаниями прокси. Это приложение может получить доступ к услугам через интернет, и я хотел бы воспользоваться встроенной инфраструктурой кэширования интернета для 'reads'. Если кэширующие прокси-серверы не могут кэшировать доставленное содержимое SSL, будет ли просто шифрование содержимого ответа жизнеспособным вариантом?
Я рассматриваю все запросы GET, которые мы хотим получить, будут запрошены через http с телом, зашифрованным с помощью асимметричного шифрования, где у каждого клиента есть ключ расшифровки. Всякий раз, когда мы хотим выполнить операцию GET, которая не является cachable, или операцию POST, она будет выполнена над SSL.
Комментарий Рори О том, что прокси-сервер должен был бы использовать самозаверяющий сертификат, если бы не был строго верен.
Прокси-сервер может быть реализован для создания нового сертификата для каждого нового узла SSL, с которым его просят иметь дело, и подписать его с общим корневым сертификатом. В сценарии OP корпоративной среды общий сертификат подписи может довольно легко быть установлен как доверенный CA на клиентских машинах, и они с радостью примут эти сертификаты "faked" SSL для проксируемого трафика, поскольку не будет никакого несоответствия имени хоста.
На самом деле именно так программное обеспечение, такое как Charles Web Debugging Proxy , позволяет проверять трафик SSL, не вызывая ошибок безопасности в браузере и т. д.
Нет, напрямую кэшировать https невозможно. Вся коммуникация между клиентом и сервером зашифрована. Прокси сидит между сервером и клиентом, для того чтобы его кэшировать, нужно уметь его читать, т. е. расшифровывать шифрование.
Вы можете сделать что-то, чтобы кэшировать его. Вы в основном делаете SSL на своем прокси-сервере, перехватывая SSL, отправленные клиенту. В основном данные шифруются между клиентом и вашим прокси-сервером, они расшифровываются, считываются и кэшируются, а данные шифруются и отправляются на сервер. Ответ с сервера также расшифровывается, читается и шифруется. Я не знаю, как вы делаете это на основных прокси-программах (например, squid), но это возможно.
Единственная проблема с этим подходом заключается в том, что прокси-сервер должен будет использовать самозаверяющий сертификат для шифрования его клиенту. Клиент сможет сказать, что прокси в середине прочитал данные, так как сертификат не будет с исходного сайта.
Я думаю, что вы должны просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая делает кэширование (например, WinInet на windows). Трудно себе представить, что преимущества корпоративного кэширования стоят того, чтобы писать пользовательскую схему шифрования безопасности или сертификат fun на прокси-сервере. Хуже того, в упомянутой вами схеме шифрования выполнение асимметричных шифров в теле сущности звучит как огромный удар perf на стороне сервера вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.
Я думаю, что вы должны просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая делает кэширование (например, WinInet на windows). Трудно себе представить, что преимущества корпоративного кэширования стоят того, чтобы писать пользовательскую схему шифрования безопасности или получать удовольствие от сертификата на прокси-сервере. Хуже того, в упомянутой вами схеме encyrption выполнение асинметрических шифров в теле сущности звучит как огромный perf-хит на серверной стороне вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.
Я думаю, что вы должны просто использовать SSL и полагаться на клиентскую библиотеку HTTP, которая делает кэширование (например, WinInet на windows). Трудно себе представить, что преимущества корпоративного кэширования стоят того, чтобы писать пользовательскую схему шифрования безопасности или получать удовольствие от сертификата на прокси-сервере. Хуже того, в упомянутой вами схеме encyrption выполнение асинметрических шифров в теле сущности звучит как огромный perf-хит на серверной стороне вашего приложения; есть причина, по которой SSL использует симметричные шифры для фактической полезной нагрузки соединения.
Рассматриваемое приложение не является браузерным приложением, это настольное приложение, которое собирает данные через интернет. Что произойдет, так это то, что все экземпляры приложения будут тянуть один и тот же кусок примерно в одно и то же время. Эти данные должны быть защищены, но я надеюсь увеличить perf, если некоторые экземпляры приложения получат кэшированную версию с корпоративного прокси-сервера.
Блоки данных невелики, но их можно часто запрашивать. По существу, все экземпляры приложения будут запрашивать одни и те же данные одновременно.
Тело данных / сообщений на стороне сервера будет предварительно зашифровано и кэшировано в распределенной таблице hash в памяти. Шифрование не будет выполняться по каждому запросу.
Я также исследую использование шины сообщений, такой как NServiceBus вместо этого.