Через 30 лет после изобретения WWW около 25% веб-сайтов все еще посещают без шифрования трафика, пишет Hackernoon. Давайте рассмотрим, в чем причина.
HTTPS – не для всех?
Итак, если войти в свой аккаунт на почтовом сервисе или в социальной сети, то все выглядит, на первый взгляд, замечательно. В названии домена есть префикс «https://», весь трафик шифруется и защищен. Но что произойдет, когда закрыть окно, а потом снова открыть веб-сайт, и уже не указывать «https://» в начале? Перейдет веб-браузер автоматически на использование протокола HTTPS для пересылки трафика? Это должно произойти, если веб-сайт правильно реализует политику HTTP Strict Transport Security (HSTS) – механизма, принудительно активирует защищенное соединение через протокол HTTPS.
Данная политика безопасности позволяет сразу же устанавливать безопасное соединение вместо использования незащищенного HTTP-протокола. Механизм применяет особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP (http://).
Эксперт по кибербезопасности Патрик Ф. Уилбур (Patrick F. Wilbur) в рамках своего исследования решил открыть новую вкладку в браузере и ввести название сайта «google.com», намеренно не указывая «https://». Он ожидал, что механизм HSTS стартует автоматически и процедура обмена данных перейдет на защищенный канал HTTPS.
Наверняка же Google, как один из самых популярных веб-сайтов в мире, должен правильно реализовывать технологию HSTS, или не так? Ответ – нет. Вводим «netflix.com " - запущена ли политика HSTS? Нет. Тогда Патрик Ф. Уилбур посетил веб-сайт популярного банка, попробовал еще несколько дополнительных популярных веб-сайтов. Нет, нет и нет – как Firefox, так и Chrome показал идентичные результаты. Но сайт «accounts.google.com» таки выполнил требования политики HSTS. Это означает, что HSTS (не всегда) применяется только для поддоменов, а не для родительских доменов популярных веб-сайтов.
Патрик Ф. Уилбур проверил, что «www.google.com», «www.netflix.com» и «github.com» никогда не переходят на незащищенный протокол HTTP. Кажется, что веб-браузеры правильно реализовали правила HSTS, но... большинство других популярных веб-сайтов выполняют политику HSTS только для поддоменов, а не для родительских доменов, или же вообще не выполняют HSTS. Это подрывает весь смысл технологии HSTS и приводит к тому, что трафик передается незашифрованным и создает удобную возможность атаки на любую общедоступную сеть.
Как проверить, применяется ли HTTP Strict Transport Security?
Перейдите на вкладку Network (Сеть) в инструментах разработчика веб-браузера Chrome, а затем введите URL-адрес, который вы ранее посетили (без префикса «https://»).
Если вы получили код статуса 307 Internal Redirect с заголовком ответа «Non-Authoritative-Reason: HSTS», то требования протокола HTTP Strict Transport Security выполняются. Если указан любой другой тип редиректа как первого редиректа, то это не так.
Следовательно, невозможно в целом объяснить, откуда берется так много опасного трафика HTTP, но, как минимум, понятно, что веб-сайты, к которым должен быть доступ только через HTTPS, не всегда настроены правильно. Это означает, что пользователи, которые не проверяют тщательно сертификаты и URL-адреса HTTPS, находятся под угрозой фишинговой атаки типа man-in-the-middle (MITM).
Но HSTS также не супернадежно
Порт UDP 123 используется протоколом NTP (Network Time Protocol) и является не шифрованным и открытым. HSTS информирует веб-браузеры, что политики HSTS должны выполняться до ранее определенного времени, то есть пока не истек их срок действия. И проблема в том, что все часовые сервисы, которые определяют это время, могут быть поддельные просто путем MITM-атаки через NTP. Это означает, что за взлом протокола NTP можно выполнить TLS/SSL-Strip атаку даже на веб-сайты, где реализован HSTS.
Кроме того, использование HSTS также вызывает значительные опасения относительно конфиденциальности. Мощные рекламные агентства, которые хотят отслеживать поведение людей на сайте, могут использовать HSTS как файлы supercookie.
DNS — означает «динозавр»
Следующая проблема связана с системой доменных имен (DNS). Вообще DNS является эффективной технологией, но чрезвычайно опасной, и об этом известно уже довольно давно. Например, стоит обратить внимание на такие пункты:
Отсутствует проверка того, что ответы с IP-адреса, полученные через DNS, действительно отправленные легитимными DNS-серверами, а не злоумышленниками.
Нет шифрования запросов DNS.
Также нет связи между записями DNS и шифрованием веб-серверов (единственным исключением является DomainKeys для уменьшения поддельной электронной спам-почты), поэтому можно подменить DNS-ответ, чтобы переадресовать запрос на опасные серверы и использовать тот факт, что политики HSTS не всегда настроены правильно.
Итак, в 2019 году мы все еще используем старую, опасную систему DNS (несмотря на такие методы, как HSTS), поэтому пользователи практически уязвимы к атакам.
Почему мы все еще не «починили» безопасность в интернете?
На этот вопрос нет короткого ответа, но можно выделить как минимум 3 пункта:
- Проблемы управления: технология дополнительной защиты https-соединений key pinning (то есть хранения списка разрешенных для домена ключей) осложняется тем, что ключи/сертификаты шифрования нужно время от времени менять, а управление этим процессом с текущими инструментами являются большой головной болью для системных администраторов. Итак, процесс key pinning полностью устарел и HSTS недостаточно для защиты публичного соединения.
- Необходимы мощные компетенции и знания в широком диапазоне: безопасность всегда сложно внедрять правильно.
- Мы просто не переживаем такую проблему и не уделяем ей достаточно внимания.
Проблемы доверия в интернете
Все вышеперечисленное осложняется еще больше тем фактом, что сегодня шифрование в интернете зависит от доверия органам сертификации (CA) для точного подтверждения подлинности ключей шифрования, которые используются во время начального «рукопожатия» между клиентом-браузером и сервером. Еще хуже, что выбор алгоритма для конфиденциального соединения происходит именно во время начального рукопожатия, то есть каждый раз избирается новый алгоритм, а сеть переполнена клиентами и серверами, которые содержат несовместимые комбинации более/менее безопасных алгоритмов и версий.
Вот как работает защищенное соединение TLS. Прежде всего, во время начального «рукопожатия» клиент Алиса (например, веб-браузер), который хочет безопасно общаться с объектом Боб (веб-сервером), должен достичь согласия с Бобом об определении канала «безопасных коммуникаций». Далее, для того, чтобы Алиса установила защищенный канал с Бобом (назовем его канал №1), Алиса к этому должна использовать другой защищенный канал связи с Бобом (канал №2) для обмена ключами для шифрования первого канала. А чтобы убедиться, что и второй канал является надежным, Алиса сначала проверяет (через канал №3) сертификационный центр «Val», чтобы быть уверенным в том, что третье лицо в интернете – Ева, которая хочет перехватить сообщение – не замаскировалось под Боба.
Итак, для того, чтобы Алиса поверила в то, что связь с Бобом защищена от чужих ушей (то есть от Евы), Алиса должна поверить Бобу, также должна поверить, что центр «Val» на самом деле не является ФБР, и к тому же довериться протоколам, которые используются для создания каналов 1, 2 и 3.
Этот процесс известен как цепь доверия. Но кто наблюдает за наблюдателями? И есть ли решение Trust No One (не доверять никому)?
Выводы
Итак, коротко о результатах исследования: большая часть веб-трафика остается незашифрованным, к тому же без уважительной причины; популярные веб-сайты, включая google.com, netflix.com и некоторыми крупными финансовыми сервисами неправильно устанавливают заголовки HTTP, связанные с безопасностью, что потенциально может подвергать пользователей атакам man-in-the-middle; DNS все еще подрывает основы защиты интернета; сеть доверия в интернете является очень сложной для правильной реализации.
В будущем в интернете должна быть принята парадигма безопасности, которая основана на недоверии, это позволит уменьшить риск и повысить прозрачность, подотчетность и аудит. Мы будем доверять только системам и (виртуальной) политике, основанные на математически доказательных и верифицированных гарантиях. Институты будут заменены сообществами, согласованными через консенсусные алгоритмы.
Обязательно ли требуется эффективное шифрование? Ответ – нет. С другой стороны, интернет построен на системах доверия и все парадигмы доверия зависят от создания безопасного и шифрованного канала. Целостность цепочек определяется самым слабым звеном, но в целом надежные безопасные каналы – это фундаментальная физическая система, которая удерживает любые коммуникации в куче. Так что в итоге надежная сеть/сеть доверия должна основываться на мощной математике.