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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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