Какой эффект трафик HTTPS имеет на веб-прокси-серверы кэша?
Я просто взял два университетских курса об интернет-программировании и компьютерной безопасности. Я думал об этом на днях:
Веб-кэш прокси-серверов кэша популярное содержание с серверов в сети. Это полезно, например, если Ваша компания имеет сетевое соединение на 1 Гбит/с внутренне (включая веб-прокси-сервер кэша), но только соединение на 100 Мбит/с с Интернетом. Веб-прокси-сервер кэша может служить кэшируемому содержанию намного более быстро другим компьютерам в локальной сети.
Теперь рассмотрите зашифрованные соединения TLS. Зашифрованное содержимое может кэшироваться каким-либо полезным способом? Существует большая инициатива со стороны letsencrypt.org, имеющего целью сделать весь интернет-трафик зашифрованным по SSL по умолчанию. Они делают это путем создания этого действительно легким, автоматизированным и свободным получить сертификаты SSL для сайта (стартовое лето 2015 года). Рассмотрение текущих ежегодных затрат для сертификатов SSL, БЕСПЛАТНЫХ, действительно привлекательно.
Мой вопрос: Трафик HTTPS в конечном счете сделает веб-прокси-серверы кэша устаревшими? Если так, какой сбор это возьмет загрузку глобального интернет-трафика?
Да, протоколы HTTP ограничивают сетевое кэширование.
В частности, потому, что для кэширования HTTP-запросов требуется проведение атаки среднего типа - замена SSL-сертификата на сертификат кеш-сервера. Этот сертификат должен быть сгенерирован на лету и подписан местным органом власти.
В корпоративной среде вы можете сделать так, чтобы все ПК доверяли вашим сертификатам кэш-сервера. Но другие машины будут выдавать ошибки сертификата - что им и должно быть. Вредоносный кеш может легко изменить страницы.
Я подозреваю, что сайты, которые используют большие объемы пропускной способности, такие как потоковое видео, будут по-прежнему отправлять контент через обычный HTTP специально, чтобы его можно было кэшировать. Но для многих сайтов лучшая безопасность перевешивает увеличение пропускной способности.
Даже жесткий HTTPS-трафик не может быть проксирован в строгом смысле слова (потому что в противном случае прокси-программное обеспечение будет действовать как « человек посередине », то есть в точности один из причина, по которой был разработан SSL, чтобы избежать ), важно отметить, что распространенные программные прокси (например, SQUID) могут правильно обрабатывать HTTPS-соединения.
Это возможно благодаря СПОСОБ СОЕДИНЕНИЯ HTTP , который SQUID правильно реализует . Другими словами, для любого HTTPS-запроса, который получает прокси-сервер, он просто "ретранслирует" его без какого-либо вмешательства в инкапсулированный зашифрованный трафик.
Даже если сначала это кажется бесполезным, это позволяет настроить локальные клиенты / браузеры на указывать на прокси-сервер и в то же время отключать любые формы подключения к Интернету.
Итак, вернемся к вашему исходному вопросу: « будет ли трафик HTTPS в конечном итоге делать прокси-серверы веб-кеша устаревшими? », мой ответ:
- ДА : если вы полагаетесь на веб-прокси только с точки зрения кэширования;
- НЕТ : если вы полагаетесь на веб-прокси для других вещей, кроме кеширования (например: аутентификация пользователя; Ведение журнала URL-адресов и т. Д.).
PS: аналогичная / основная проблема с HTTPS связана с множественной адресацией виртуальных хостов на основе имен, которая часто встречается в решениях веб-хостинга, но ... усложняется при работе с HTTPS-сайтами (Я не обсуждаю подробно, потому что это не связано строго с этим вопросом).
https побеждает некоторые типы безопасности, которые ранее были реализованы в прокси-серверах. Учтите, что squid может перехватить и заменить страницу локальным контентом (функция, которую я использую довольно часто). Раньше я перехватывал ссылки из поисков Google, и мой прокси перенаправлял их прямо на ссылку, тем самым повышая свою безопасность, не раскрывая, по каким ссылкам я (или кто-либо другой в моей локальной сети, кто решил использовать прокси) перешел на Google. Используя https, Google одержал победу над этим аспектом моей безопасности (который, конечно же, был человеком в средней атаке). Теперь мне придется взломать код браузера, что гораздо больше усилий ... и не доступен для других пользователей в домашнем хозяйстве, если они также, рады запустить локально взломанные браузеры.
.