HTTP Strict Transport Security (HSTS) — это стандарт безопасности, который позволяет веб-сайту объявить себя доступным только по безопасным соединениям, а браузерам передаётся информация для редиректа. Веб-браузеры с поддержкой HSTS ещё и не позволяют пользователям игнорировать ошибки сертификатов на серверах.

Apple использует HSTS, например, на iCloud.com, так что каждый раз при попытке перейти по незащищённому адресу http://www.icloud.com из адресной строки браузера или по ссылке происходит автоматический редирект на https://www.icloud.com. Это отличная функция, которая предотвращает простые ошибки, например, по выполнению финансовых операций на канале без аутентификации.

Что здесь может быть не так?

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

HSTS как постоянный межсайтовый идентификатор (суперкуки)

Злоумышленник, который стремится отслеживать посетителей сайта, может использовать бит информации из кэша HSTS на устройстве пользователя. Например, «загружать этот домен по HTTPS» представляет 1, а отсутствие записи — 0. Зарегистрировав некоторое большое количество доменов (например, 32 или более) и инициировав загрузку ресурсов с контролируемого подмножества, можно получить достаточно большое битовое пространство для уникального представления каждого посетителя сайта.

Авторы HSTS признали такую возможность в разделе 14.9 спецификаций («Креативное манипулирование запоминанием политики HSTS»):

… для тех, кто контролирует один или более HSTS-компьютеров, имеется возможность кодировать информацию в доменных именах и вынудить такие агенты пользователя кэшировать эту информацию в процессе пометки HSTS-компьютеров. Эта информация может быть извлечена другими компьютерами путём соответствующего конструирования и загрузки веб-ресурсов, вынуждая агента пользователя посылать запросы для закодированных доменных имён.

При первом посещении сайта:

• Посетителю присваивается случайный номер, например, 8396804.
• Он преобразуется в двоичное значение (например, 10000000001000000000000100).
• Скрипт трекера запрашивает подресурсы с контролируемых доменов по https, один запрос на один бит трекинг-идентификатора.
  
  • https://bit02.example.com
  • https://bit13.example.com
  • https://bit23.example.com
  • … и так далее.
• Сервер отвечает на каждый HTTPS-запрос заголовком ответа HSTS, который кэширует значение в веб-браузере.
• Теперь мы гарантированно загрузим HTTPS-версию bit02.example.com, bit13.example.com и bit23.example.com, даже если пользователь инициирует загрузку по HTTP.

При последующих посещениях веб-сайта:

• Скрипт трекера загружает 32 невидимых пикселя по HTTP, соответствующие битам в двоичном числе.
• Поскольку некоторые из этих битов (bit02.example.com, bit13.example.com и bit23.example.com в нашем примере) уже были загружены с HSTS, то для них осуществляется автоматический редирект на HTTPS.
• Сервер отслеживания передаёт одно изображение при запросе по HTTP, а другое — при запросе по HTTPS.
• Скрипт трекинга распознаёт разные изображения, превращает их в нули (HTTP) и единицы (HTTPS) двоичного числа, и вуаля — ваш уникальный двоичный идентификатор воссоздан, и теперь вас отслеживают!

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

Задачи

Риски конфиденциальности из-за HSTS периодически обсуждаются в прессе как теоретические. В отсутствие доказательств злонамеренного злоупотребления протоколом HSTS разработчики браузеров придерживались осторожности и послушно выполняли все инструкции HSTS от сайтов.

Недавно нам стало известно, что эта теоретическая атака в реальности используется против пользователей Safari. Поэтому мы разработали сбалансированное решение, которое сохраняет безопасность веб-трафика при одновременной защите от слежки.

Решение Apple

Эксплойт HSTS состоит из двух этапов: 1) создание идентификатора отслеживания; 2) операция чтения. Мы решили установить защиту на обоих этапах.

Защита 1: Ограничить установку HSTS только именем хоста или TLD+1

Мы заметили, что сайты трекеров конструируют длинные URL, в которых закодированы цифры на разных уровнях доменного имени.

Например:

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…и т.д...

Также мы заметили, что сайты трекеров используют большое количество родственных доменных имен, например:

https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...и т.д...
https://bit64.example.com

Телеметрия показала, что злоумышленники устанавливают HSTS одновременно для широкого диапазона поддоменов. Поскольку использование HSTS таким образом не соответствует нормальному использованию, но облегчает трекинг, мы изменили сетевой стек, чтобы разрешить установку HSTS только для загруженного имени хоста (например, https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com) или TLD+1 (например, https://example.com).

Это не позволяет трекерам эффективно устанавливать большое количество бит HSTS. Вместо этого нужно отдельно зайти на каждый домен, представляющий бит в идентификаторе отслеживания. В то же время контент-провайдеры и рекламодатели могут решить, что для них неприемлема задержка из-за редиректа на 32 и более домена. WebKit также ограничивает размер цепочки редиректов, что ограничивает максимальное количество бит в идентификаторе даже если злоумышленники признали задержку приемлемой.

Это решает проблему установки суперкуков.

Защита 2: игнорировать состояние HSTS для запросов подресурсов с заблокированных доменов

Мы модифицировали WebKit так, что теперь игнорируются запросы на обновление состояния HSTS и просто используется исходный URL, если ссылка на загрузку небезопасного подресурса идёт с домена, для которого заблокированы куки (например, невидимые пиксели отслеживания). Это приводит к тому, что битовые идентификаторы суперкуков HSTS состоят только из нулей.

Вывод

Собранная во время внутреннего регрессионного тестирования и с финальных версий общедоступного ПО телеметрия указывает, что две описанные защиты успешно предотвратили создание и чтение суперкуков HSTS, не ухудшив защиту на сайте. Мы считаем, что они соответствуют передовой практике и обеспечивают важные меры безопасности, предоставляемые HSTS. Мы поделились деталями первой защиты с авторами RFC 6797 (HSTS) и работаем над тем, чтобы сделать этот механизм частью стандарта.