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