HSTS
HSTS (скор. від англ. HTTP Strict Transport Security) — механізм, який примусово активує захищене з'єднання через протокол HTTPS. Дана політика безпеки дозволяє відразу ж встановлювати безпечне з'єднання замість використання HTTP-протоколу. Механізм використовує особливий заголовок Strict-Transport-Security для примусового використання браузером протоколу HTTPS навіть у разі переходу по посиланнях з явним зазначенням протоколу HTTP (http://). Механізм специфікований в [rfc:6797 RFC6797] в листопаді 2012 року.
HSTS допомагає запобігти частині атак, спрямованих на перехоплення з'єднання між користувачем і вебсайтом, зокрема [1]атаку з пониженням ступеня захисту і крадіжку cookie's.
Додатковий захист https-з'єднань надають методи Certificate pinning (зберігання списку дозволених для домену сертифікатів або CA у вихідних текстах браузера) і HTTP Public Key Pinning[en]. Вони запобігають безліч можливостей підміни 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://uk.wikipedia.org/wiki/HSTS браузер буде використовувати https://uk.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, однак такий підхід погано масштабується.
Станом на кінець 2014 року, в статичному списку знаходилося більше тисячі доменів, з них близько чверті — домени Google[10].
Використання[ред. | ред. код]
- На клієнтській стороні
- Chromium 4 і всі браузери на його основі[11].
- Firefox 4[12]
- NoScript[13]
- На стороні сайту (всі перераховані включені в HSTS preload list):[14]
Дивись також[ред. | ред. код]
- HTTPS Everywhere
Примітки[ред. | ред. код]
- ↑ HTTP Strict Transport Security. Mozilla Developer Network. Архів оригіналу за 18 березня 2014. Процитовано 12 червня 2015.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 5. HSTS Mechanism Overview. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 21 листопада 2012.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 12.1. No User Recourse. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 30 червня 2014.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). 2.3. Threat Model. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 21 листопада 2012.
- ↑ HSTS [Архівовано 3 квітня 2018 у Wayback Machine.] / Chromium — Preloaded HSTS sites
- ↑ 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.
- ↑ 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
- ↑ HSTS Preloading. Архів оригіналу за 3 квітня 2018. Процитовано 3 квітня 2018.
- ↑ Preloading HSTS [Архівовано 24 лютого 2020 у Wayback Machine.] / 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 (26 січня 2010). Security in Depth: New Security Features. Chromium Blog. Архів оригіналу за 13 серпня 2011. Процитовано 19 листопада 2010.
- ↑ Sid Stamm (26 серпня 2010). HTTP Strict Transport Security has landed!. Архів оригіналу за 4 липня 2012. Процитовано 19 листопада 2010.
- ↑ Giorgio (23 сентября 2009). Strict Transport Security in NoScript. Архів оригіналу за 4 липня 2012. Процитовано 19 листопада 2010.
- ↑ Preloaded HSTS sites [Архівовано 18 лютого 2020 у Wayback Machine.] / Chromium
Посилання[ред. | ред. код]
- [rfc:6797 Специфікація 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, . — ISBN 1-891562-38-X. — DOI:.