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

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

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

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

18.08.2008 14:06:13
По состоянию на 2018 г. наиболее эффективным решением для кэширования ресурсов, обслуживаемых по HTTPS, является использование сервисного работника . Такие библиотеки, как Workbox, упрощают управление кешами.
Dan Dascalescu 7.08.2018 22:52:44
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

19
18.08.2008 14:24:39
Есть ли способ сделать 2 байта запросов https равными, чтобы прокси-сервер мог вернуть кэшированный ответ?
Pacerier 21.06.2017 04:42:29
Зашифрованный туннель TLS не позволяет видеть заголовки HTTP, что означает, что вы не можете различить отдельные ответы. Таким образом, даже байтовые пакеты не могут быть кэшированы
Ben Winding 19.04.2018 05:53:27

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

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

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

23
23.08.2008 00:19:47
Я был бы очень взволнован, чтобы найти это в любой среде, кроме тестирования; Надеемся, что это незаконно в большинстве стран из-за того, что он может открыть червей - например, если финансовый директор проверяет банковские счета компании через веб-портал, они, вероятно, будут недовольны, узнав, что ИТ-отдел может перехватить взаимодействие.
Phil Lello 10.03.2016 18:22:43
@Phil Это в основном то, что делают провайдеры обратного прокси. То, что соединение с веб-сайтом (обратный прокси-сервер) является безопасным, не означает, что ваши данные передаются в зашифрованном виде до конечной точки.
None 9.12.2016 01:15:18
@ J.Money Да, но вопрос, в частности, связан с подключением через браузер в сети A через прокси-сервер к серверу B. Что после этого выполняет сервер B, это совершенно отдельная проблема, и даже сквозное шифрование с взаимной аутентификацией не гарантирует, что обмен данными используется ответственно / законно / по назначению
Phil Lello 9.12.2016 13:30:57

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

1
26.03.2016 17:56:47

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

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

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

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

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

1
25.08.2008 21:37:54

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

1
5.11.2008 02:52:20
Это не путем отказа от сертификата. В корпоративной среде рабочая станция будет доверять компании CA, и она используется BlueCoat для отказа от связи. Так оно и есть: site - [https] -> Bluecoat - [https] -> Пользователь
Antoine 'hashar' Musso 14.09.2015 20:07:37

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

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

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)
0
18.05.2010 21:26:12