HSTS

HSTS (сокр. от англ. HTTP Strict Transport Security) — механизм, принудительно активирующий защищённое соединение через протокол HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение вместо использования HTTP-протокола. Механизм использует особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP (http://). Механизм описан в RFC6797 в ноябре 2012 года.

HSTS помогает предотвратить часть атак, направленных на перехват соединения между пользователем и веб-сайтом, в частности атаку с понижением степени защиты и угон куки (cookie).

Дополнительную защиту https-соединений предоставляют методы Certificate pinning (хранение списка разрешенных для домена сертификатов или CA в исходных текстах браузера) и HTTP Public Key Pinning. Они предотвращают множество возможностей подмены tls-сертификатов https-сервера.

Спецификация

Спецификация была разработана и предложена Джеффом Оджом (=JeffH, Paypal), Адамом Бартом (Университет Беркли), Колином Джексоном (Университет Карнеги — Меллон). После обсуждения в рабочей группе IETF WebSec спецификация была принята в качестве RFC 19 ноября 2012 года.

Механизм

Сервер сообщает о политиках HSTS с помощью специального заголовка при подключении через шифрованный HTTPS (заголовок HSTS при подключении по нешифрованному HTTP игнорируется)[1]. Например, сервера Википедии посылают заголовок HSTS со сроком действия 1 год, распространяющийся на все поддомены (Поле max-age указывает срок действия в секундах, величина 31536000 приблизительно соответствует одному году): Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Когда сайт применяет политику HSTS, пользовательские браузеры, корректно воспринимающие заголовок HSTS, должны[2]:

  1. Автоматически автономно преобразовывать все http-ссылки на данный сайт в https-ссылки. (Например, вместо http://ru.wikipedia.org/wiki/HSTS браузер будет использовать https://ru.wikipedia.org/wiki/HSTS, преобразование произойдет до реального обращения к серверу.)
  2. Если безопасность соединения https не может быть проверена (в частности, если TLS-сертификат сервера не подписан доверенным ключом), будет показано сообщение об ошибке, и пользователь будет лишен доступа к сайту[3].

Действующие политики HSTS помогают защитить пользователей сайта от части пассивных и активных атак[4]. Атаки класса MiTM значительно усложняются.

Статический список HSTS

Исходный вариант HSTS не защищает первое подключение пользователя к сайту. Злоумышленник может легко перехватить первое подключение, если оно происходит по протоколу http. Для борьбы с этой проблемой большинство современных браузеров использует дополнительный статический список сайтов (HSTS preload list), требующих использования протокола https. Такой список составляется авторами Google Chrome/Chromium с 2010 года[5][6], на базе него составляются подобные списки для браузеров Microsoft (Edge и Internet Explorer, с 2015 года)[7], Safari[8] и в Mozilla Firefox (с 2012 года)[9]. В подобный список по запросу включаются сайты, использующие HSTS-заголовок с максимальным сроком и флагом preload, и не планирующие отказ от https[9], однако технология плохо масштабируется[8].

По состоянию на конец 2014 года, в статическом списке находилось более тысячи доменов, из них около четверти — домены Google[10].

Использование

Страница отладки HSTS и HPKP в браузере Chromium для сайта en.wikipedia.org (до внесения в список HSTS preload, динамический HSTS; HPKP не применяется).

Отслеживание с помощью HSTS

HSTS может быть использован для трудноподавляемого маркирования браузеров высокоустойчивыми метками (см. также Супер-cookie) независимо от использования режима «инкогнито»[15].

Браузер Mozilla Firefox начиная с версии 85 предоставляет средства противодействия отслеживанию основанному на HSTS-кэшировании[16].

Примечания

  1. ↑ HTTP Strict Transport Security. Mozilla Developer Network. Дата обращения: 12 июня 2015. Архивировано 18 марта 2014 года.
  2. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam.: . Section 5. HSTS Mechanism Overview. RFC 6797. IETF (ноябрь 2012). Дата обращения: 21 ноября 2012. Архивировано 26 февраля 2020 года.
  3. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam.: . Section 12.1. No User Recourse. RFC 6797. IETF (ноябрь 2012). Дата обращения: 30 июня 2014. Архивировано 26 февраля 2020 года.
  4. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam.: . 2.3. Threat Model. RFC 6797. IETF (ноябрь 2012). Дата обращения: 21 ноября 2012. Архивировано 26 февраля 2020 года.
  5. ↑ HSTS Архивная копия от 3 апреля 2018 на Wayback Machine / Chromium — Preloaded HSTS sites
  6. ↑ https://hstspreload.appspot.com/ Архивная копия от 7 февраля 2015 на Wayback Machine This form is used to submit domains for inclusion in Chrome’s HTTP Strict Transport Security (HSTS) preload list.
  7. ↑ HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7 Архивная копия от 27 ноября 2019 на Wayback Machine / Microsoft Enge Blog, 2015-06-09
  8. ↑ 1 2 HSTS Preloading. Дата обращения: 17 сентября 2015. Архивировано 3 апреля 2018 года.
  9. ↑ 1 2 Preloading HSTS Архивная копия от 24 февраля 2020 на Wayback Machine / Mozilla Security Blog, 2012
  10. ↑ Upgrading HTTPS in Mid-Air: An Empirical Study of Strict Transport Security and Key Pinning Архивная копия от 4 марта 2016 на Wayback Machine / NDSS ’15, 8-11 February 2015 // Internet Society, ISBN 1-891562-38-X doi:10.14722/ndss.2015.23162  (англ.)
  11. ↑ Adam Barth. Security in Depth: New Security Features (англ.). Chromium Blog (26 января 2010). Дата обращения: 19 ноября 2010. Архивировано из оригинала 13 августа 2011 года.
  12. ↑ Sid Stamm. HTTP Strict Transport Security has landed! (англ.) (26 августа 2010). Дата обращения: 19 ноября 2010. Архивировано из оригинала 4 июля 2012 года.
  13. ↑ Giorgio. Strict Transport Security in NoScript (англ.) (23 сентября 2009). Дата обращения: 19 ноября 2010. Архивировано из оригинала 4 июля 2012 года.
  14. ↑ Preloaded HSTS sites Архивная копия от 18 февраля 2020 на Wayback Machine / Chromium
  15. ↑ Mark Stockley. Anatomy of a browser dilemma – how HSTS ‘supercookies’ make you choose between privacy or security (англ.). Naked Security. Sophos (2 февраля 2015). Дата обращения: 1 июля 2024. Архивировано из оригинала 11 февраля 2020 года.
  16. ↑ Steven Englehardt and Arthur Edelstein. Firefox 85 Cracks Down on Supercookies (англ.). Mozilla Security Blog (26 января 2021). Дата обращения: 1 июля 2024. Архивировано 3 февраля 2021 года.

Ссылки

Эта статья взята у (из) Википедия. Текст лицензируется по Creative Commons Attribution-Share Alike 4.0. К медиа файлам могут применятся дополнительные условия.