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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Я думаю о чем-то подобном этому:

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