Непрозрачное прокси-кэширование SSL - PullRequest
1 голос
/ 11 октября 2009

Я задавал вопрос раньше, но не совсем правильно сформулировал. Я использую принципы RESTful для создания защищенного веб-приложения, которое использует как транспортную аутентификацию / шифрование, так и безопасность на уровне сообщений.

Безопасность на уровне сообщений по существу не зависит от клиента (хотя все еще шифруется), и, следовательно, позволяет кэшировать отдельные сообщения или сохранять их на сервере-посреднике без существенного риска раскрытия личных данных.

Безопасность на транспортном уровне необходима для аутентификации обеих конечных точек с использованием аутентификации клиента TLS. Ситуация аналогична наличию центрального мэйнфрейма, откуда отправляются сообщения, и кешируется в каждом филиале, где расположены клиенты. Я хочу, чтобы соединения client-> cache и cache-> mainframe были защищены с использованием TLS и отдельных сертификатов X509. Следовательно, клиент будет знать, что он разговаривает с прокси, а мэйнфрейм узнает, что он разговаривает с прокси, а не напрямую с клиентом.

Есть ли какой-нибудь способ сделать это с помощью стандартов HTTP, а не путем какого-то взлома?

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

Кто-нибудь знает программу прокси / кэширования или метод, который позволит это?

Ответы [ 2 ]

0 голосов
/ 11 октября 2009

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

Кикер - это сообщение безопасности. Это будет работать только в том случае, если ваши запросы кэшируются на 100% только на основе пути / строки запроса, и если они были «уникальными для клиента» (например, идентификатор клиента в QS или что-то в этом роде). Что-то говорит мне, что один или оба из них не соответствуют действительности. Это было бы довольно тривиально для сборки в ASP.NET или путем расширения mod_cache (в основном, просто стандартное кэширование ответов, с привязкой к отпечатку пальца клиента).

0 голосов
/ 11 октября 2009

Получит ли это больше ответов на serverfault.com, так как это вопрос программного обеспечения / конфигурации сервера, а не проблема программирования как таковая?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...