VOOZH about

URL: https://ru.wikipedia.org/wiki/HSTS

⇱ HSTS — Википедия

Перейти к содержанию
Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 28 мая 2022 года; проверки требуют 13 правок.

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 браузер будет использовать , преобразование произойдет до реального обращения к серверу.)
  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].

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

[править | править код]
👁 Image
Страница отладки 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 года.
Категория:
Скрытые категории: