Предупреждён – значит вооружён: от чего не спасает HTTPS

HTTPS — очень важная для интернета технология: она охраняет наш трафик и все веб-сайты в интернете должны использовать её. Есть ряд ограничений ко всем бонусам, которые предоставляет даже правильно настроенный HTTPS. В данной статье попробуем в этих ограничениях разобраться.

HTTPS работает только тогда, когда его используют

На практике основная ошибка в использовании HTTPS, приводящая к уязвимостям, заключается в том, что он работает не постоянно.

Указывайте https:// в каждом веб-адресе, включая документацию, почту, рекламу и т.д. Используйте HSTS, директивы Upgrade-Insecure-Requests и Block-All-Mixed-Content для того, чтобы избежать ошибок при вводе URL с HTTPS.

Смешанное содержимое — браузеры будут блокировать небезопасные скрипты и CSS (так называемое активное смешанное содержимое). В свою очередь, изображения и другое «пассивное смешанное содержимое» будет запрашиваться с сервера и появляться на экране.

Небезопасные ссылки — браузеры умеют бороться с активным и пассивным смешанным контентом на страницах, но большинство из них ничего не делает по поводу так называемого «латентного» смешанного контента — небезопасных ссылок на вполне себе безопасных страницах.

Ограничения приватности

SNI/IP-адрес — когда вы подключаетесь к серверу через HTTPS, URL остаётся в зашифрованном виде, и другие пользователи сети не смогут понять, что вы делаете. Однако эти пользователи вполне могут узнать IP-адрес, к которому вы подключились, и имя хоста, которое вы запрашиваете, например, используя расширение ClientHello.

TLS 1.3 предлагает средства для SNI-шифрования, но злоумышленник, скорее всего, сможет догадаться, к какому серверу вы подключены, исключительно по IP-адресу (если вы, конечно, не сидите через TOR).

Количество данных – когда вы подключаетесь к серверу через HTTPS, данные, которые вы отправляете и получаете, зашифрованы, однако в большинстве случаев количество данных не маскируется. Пользуясь этим, злоумышленик, который знает, на каком сайте вы сидите, сможет понять тип передаваемых или получаемых данных. Протоколы вроде HTTP/2 имеют возможность формировать сдвиги для маскировки количества данных. Также некоторые сайты могут сами предпринимать меры для обеспечения приватности.

Для совершения подобных атак используется множество различных характеристик конкретно вашего трафика, чтобы определить, чем вы там занимаетесь. Злоумышленниками, кстати, зачастую выступают не только мошенники, но и целые государства: такие атаки лежат в основе так называемого «Великого Китайского Фаервола». Атаки, именуемые «BREACH», пользуются особенностью сжатия трафика в HTTP. Даже небольшая утечка способна полностью раскрыть содержимое передаваемых данных.

Заголовок Referer — по умолчанию браузер отправляет URL страницы через «Referer», когда перенаправляет с одной HTTPS-страницы на другую. В нём, как правило, содержится адрес сайта, с которого вы перешли, а также некоторая информация о вас. Обычно она используется серверным кодом сайта, на который вы перешли, для анализа ваших поисковых запросов и т.д. Такой URL в руках злоумышленника предоставит ему достаточно полную информацию о вашем трафике.

Ограничения, связанные с идентификацией сервера

Процедура  верификации сертификата — во время HTTPS-рукопожатия, которое используется для согласования данных сессии между клиентом и сервером, сервер предоставляет сертификат, позволяющий идентифицировать себя. Таких сертификатов существует множество, и самый популярный — сертификат с проверкой домена. Оно и неудивительно: процесс получения такого сертификата не занимает больше 10 минут и не требует никаких документов. От вас нужно только подтверждение того, что вы владеете конкретным доменом.

Такая простота проверки будущего владельца сертификата даёт возможность злоумышленнику получить сертификат верификации на сайт, который очень напоминает оригинал. Конечно, домен https://paypal.com он не сможет зарегистрировать, но https://paypal.co.com — вполне.

Для избежания таких вариантов развития событий существуют более сложные для получения сертификаты. Один из них — сертификат с расширенной проверкой. Их используют банки и системы оплаты. На сайтах с таким сертификатом адресная строка окрашивается в зелёный цвет и даёт понять всем пользователям, что вы заботитесь об их безопасности. Получение такого сертификата — очень трудоёмкий процесс, требующий предъявления документов и т.д.

Иногда злоумышленники пользуются отсутствием достаточной эрудированности пользователя. Наличие полей «логин», «пароль», «номер кредитки» на случайном сайте с похожим на оригинал интерфейсом иногда внушает доверие неопытному пользователю сети.

Одноуровневая безопасность — TLS зачастую делает безопасным соединение только на одном уровне. К примеру, давайте перейдём на сайт https://fiddlerbook.com. HTTPS в начале адреса внушает доверие, ура! Однако не всё так радужно. Вы вряд ли знали, что этот домен работает с бесплатным CDN от Cloudflare: и хоть ваше соединение с данным CDN вполне безопасное, связь сервера с CDN идёт через обыкновенный HTTP.

Проблема DOM — устанавливая соединение с https://www.example.com, вы обычно уверены, что верхний уровень страницы идёт непосредственно с сервера example.com. Но на практике запрашиваемые HTML-страницы часто используют различные сторонние сервисы, которые не всегда безопасны. Это особенно интересно на сайтах с упомянутыми выше сертификатами с расширенной проверкой. Вполне себе безопасные ресурсы содержат скрипты от сторонних сервисов с обычным сертификатом с проверкой домена или вообще без такового.

Компрометирование сервера — если случилось так, что сервер был скомпрометирован из-за бага, ошибки или чего-нибудь ещё, HTTPS не поможет. Более того, HTTPS даже не всегда даст понять вам то, что сервер был атакован.

Банальные баги — очевиден тот факт, что HTTPS не спасёт вас от багов в серверном коде:

Ограничения со стороны клиента

Аутентификация клиента — в HTTPS есть поддержка клиентской аутентификации, которая заключается в предоставлении сертификата, подтверждающего «подлинность» клиента. На практике это практически нигде не используется.

Атака посредника — большинство разработчиков подразумевают, что данные, отправленные клиентом, исходят от этого клиента и не были подвергнуты никаким манипуляциям. Однако существует вероятность атаки человека посередине (Man-In-The-Middle), когда злоумышленник входит в канал связи между клиентом и сервером и проводит манипуляции с данными, удаляя или искажая информацию.

HPKP (HTTP Public Key Pinning) — механизм защиты, благодаря которому удаётся достигнуть снижения риска атаки человека в браузере (Man-In-The-Browser). Однако браузеры Chrome и Firefox отключают этот механизм, если полученный сертификат привязан к установленному пользователем корневому сертификату.

Иногда человек даже ни при чем в подобных атаках. HTTPS защищает данные, пока они в пути, но как только они достигают клиента, HTTPS ничего с ними не делает. Атака человека в браузере происходит, когда клиентская программа (браузер) была атакована вредоносным ПО, так что подмена данных или утечка происходит до шифрования или после дешифрования.

Ограничения в реализации

Усечённые данные — TLS помогает определить, когда данные не были полностью переданы для предотвращения получения неполных данных. На практике эти средства редко используются самими клиентами.

Переопределение ошибок — проблемы HTTPS настолько распространены, что у пользователя иногда появляется возможность переопределения ошибок, возникших во время проверки сертификата (истёкшие сроки сертификатов, несоответствие имён и т.д.). Разные клиенты отличаются друг от друга в том, насколько хорошо они предоставляют пользователю эти ошибки и не позволяют ему их проигнорировать.