Ответ командования флота, как написано в настоящее время, в основном правильный. Я не хочу дублировать этот ответ, поэтому я рекомендую начать с чтения этого ответа (полностью).
Тем не менее, есть один момент, который следует уточнить. (Я подумал, что это займет больше символов, чем комментарий, поэтому я добавляю его в качестве ответа.)
Чтобы обойти это обнаружение, человек-посредник должен каким-то образом получить пары ключей цифрового сертификата исходного защищенного сервера.
Это всего лишь один подход. Есть другой подход: «человек посередине» может просто использовать свой собственный сертификат. Этот метод выполняется многими организациями (включая коммерческие компании, государственные школы и т.д.)
Например, у вас может быть межсетевой экран, который обеспечивает возможности «HTTPS-фильтрации». Этот брандмауэр может получать исходящий HTTPS-трафик, и вместо того, чтобы направлять его на веб-сайт, брандмауэр может действовать так, как если бы он был веб-сайтом. Затем брандмауэр устанавливает свое собственное HTTPS-соединение с веб-сайтом, извлекает данные с этого веб-сайта и передает данные в веб-браузер (следит за трафиком и производит любые желаемые фильтрацию / изменения по желанию брандмауэра).
Проблема заключается в том, что, если устройство "человек посередине" (в данном примере "брандмауэр") не решит ключевую проблему, веб-браузер будет знать, что данные не приходят с веб-сайта, который он пытался достигать. Веб-браузер узнает, что веб-сайт - это то, чего он хочет достичь, используя технологию SSL. (Исторически, хотя S в HTTPS означало "Безопасный", технически правильно было думать о нем как "HTTP поверх SSL"). Хотя, в настоящее время это обычно "HTTP поверх TLS".)
Как отметил Fleet Command, один из способов справиться с этой проблемой - получить закрытые ключи сайта. Однако есть и другой способ.
Когда веб-браузер получает сертификат SSL (который содержит некоторую информацию, включая ключ SSL), независимо от того, поступает ли он с фактического веб-сайта или с устройства «человек посередине», веб-браузер проверяет, является ли этот SSL Сертификат должен быть доверенным, чтобы идентифицировать себя как веб-сайт. Обычный способ сделать это для веб-браузера, чтобы посмотреть в своем хранилище сертификатов. Давайте рассмотрим три различных сценария того, что происходит, когда кто-то пытается посетить веб-сайт Example.com, и затем вы увидите другой возможный недостаток, который позволяет HTTPS-фильтрации работать.
- Если на вашем веб-сайте написано «Я - Example.com, и вы знаете это из-за моего SSL-сертификата, который, как вы можете сказать, одобрен GoDaddy.com», и если ваш веб-браузер использует хранилище сертификатов, которое имеет сертификат, который говорит, что доверяет всему одобренному GoDaddy.com, то веб-браузер удовлетворен, и вы не жалуетесь.
- Если вы идете в ресторан и подключаетесь к устройству Wi-Fi, которое пытается использовать методы "человека посередине", чтобы шпионить за вами, а устройство Wi-Fi говорит: «Я - Example.com, и вы знаете, это из-за моего SSL-сертификата, который вы можете сказать, одобрен Cyberoam ". Тем не менее, ваш веб-браузер не содержит сертификат, который говорит, что он должен доверять Cyberoam. В результате веб-браузер отображает пользователю предупреждение о том, что связь с веб-сайтом не заслуживает доверия, поскольку сертификат кажется недействительным.
- Однако затем вы идете на работу и говорите, что ваш компьютер должен присоединиться к домену Active Directory по соображениям безопасности. Вы соглашаетесь, и тогда ваш компьютер доверяет "контроллеру домена" сети для внесения любых изменений в конфигурацию безопасности. Компания Work хочет управлять трафиком HTTPS, поэтому контроллер домена указывает, что сертификат Cyberoam должен быть установлен в хранилище сертификатов вашего компьютера. Теперь ваша работа может следить не только за вашим HTTPS-трафиком (даже если вы об этом не знаете), но и за устройством Wi-Fi, расположенным рядом с рестораном.
В целом, позиция многих организаций такова: «Мы хотим что-то контролировать, и нас не волнует, есть ли у конечных пользователей конфиденциальность, которую они желают». Вот еще один пример такого же рода событий: безопасность.Вопрос StackExchange.com: "Мой колледж заставляет меня установить их сертификат SSL".
Я думаю о том, сколько людей просто выбирают "я согласен", не читая форм и не понимая последствий для безопасности. До тех пор, пока большинство обычных людей будут просто сотрудничать с шагами, когда организация говорит, что "это необходимо", и до тех пор, пока организации склонны придерживаться такого контрольного отношения, рынок, кажется, созрел для компаний, чтобы продолжать продавать оборудование, предназначенное для того, чтобы отслеживание HTTPS-трафика с использованием закрытых ключей, и для организаций, чтобы эти закрытые ключи были установлены на компьютерах (чтобы оборудование могло эффективно выполнять запланированную задачу отслеживания HTTPS-трафика).
Теперь, когда я обсудил технологию, эффективно отвечая на вопрос в заголовке («В какой степени возможна фильтрация трафика HTTPS?»)."), позвольте мне дать прямой ответ на другой вопрос, который я вижу:
Можно ли заблокировать загрузку на веб-сайты встроенного HTTPS-контента, такого как видео YouTube?
Как отмечается в ответе Fleet Command, брандмауэры могут просто заметить, что IP-адрес назначения связан с YouTube, и блокировать трафик там. Конечный пользователь будет знать, что трафик заблокирован, потому что страница не будет загружаться.
Если методы MITM внедряются, то устройство теоретически может позволить веб-браузеру получать некоторый контент с веб-сайта, в то время как другой контент может быть изменен (в том числе заблокирован). Например, видео может быть разрешено, но комментарии могут быть изменены (или наоборот). Конечный пользователь, вероятно, будет не замечать происходящего.
