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]:
- Автоматически автономно преобразовывать все http-ссылки на данный сайт в https-ссылки. (Например, вместо http://ru.wikipedia.org/wiki/HSTS браузер будет использовать https://ru.wikipedia.org/wiki/HSTS, преобразование произойдет до реального обращения к серверу.)
- Если безопасность соединения 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
HSTS может быть использован для трудно-подавляемого маркирования браузеров высокоустойчивыми метками (см. также Супер-cookie) независимо от использования режима "инкогнито".[15]
Браузер Mozilla Firefox начиная с версии 85 предоставляет средства противодействия отслеживанию основанному на HSTS-кэшировании[16].
См. также
Примечания
- HTTP Strict Transport Security . Mozilla Developer Network. Дата обращения: 12 июня 2015.
- Hodges, Jeff; Jackson, Collin; Barth, Adam. Section 5. HSTS Mechanism Overview . RFC 6797. IETF (November 2012). Дата обращения: 21 ноября 2012.
- Hodges, Jeff; Jackson, Collin; Barth, Adam. Section 12.1. No User Recourse . RFC 6797. IETF (November 2012). Дата обращения: 30 июня 2014.
- Hodges, Jeff; Jackson, Collin; Barth, Adam. 2.3. Threat Model . RFC 6797. IETF (November 2012). Дата обращения: 21 ноября 2012.
- HSTS / Chromium — Preloaded HSTS sites
- https://hstspreload.appspot.com/ This form is used to submit domains for inclusion in Chrome’s HTTP Strict Transport Security (HSTS) preload list.
- HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7 / Microsoft Enge Blog, 2015-06-09
- HSTS Preloading
- Preloading HSTS / Mozilla Security Blog, 2012
- 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 (англ.)
- Adam Barth. Security in Depth: New Security Features (англ.) (недоступная ссылка). Chromium Blog (26 января 2010). Дата обращения: 19 ноября 2010. Архивировано 13 августа 2011 года.
- Sid Stamm. HTTP Strict Transport Security has landed! (англ.) (недоступная ссылка) (26 августа 2010). Дата обращения: 19 ноября 2010. Архивировано 4 июля 2012 года.
- Giorgio. Strict Transport Security in NoScript (англ.) (недоступная ссылка) (23 сентября 2009). Дата обращения: 19 ноября 2010. Архивировано 4 июля 2012 года.
- Preloaded HSTS sites / Chromium
- The HSTS super cookie forcing you to choose: "privacy or security?" - . sophos.com. Дата обращения: 1 декабря 2015.
- Firefox 85 Cracks Down on Supercookies – Mozilla Security Blog - . mozilla.org. Дата обращения: 19 февраля 2021.
Ссылки
- Спецификация HTTP Strict Transport Security (HSTS) RFC 6797, ноябрь 2012 (англ.)
- Upgrading HTTPS in Mid-Air: An Empirical Study of Strict Transport Security and Key Pinning / NDSS ’15, 8-11 February 2015 // Internet Society, ISBN 1-891562-38-X doi:10.14722/ndss.2015.23162 (англ.)