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. Процитовано 12 June 2015.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 5. HSTS Mechanism Overview. RFC 6797. IETF. Процитовано 21 November 2012.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 12.1. No User Recourse. RFC 6797. IETF. Процитовано 30 June 2014.
- ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). 2.3. Threat Model. RFC 6797. IETF. Процитовано 21 November 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 (January 26, 2010). Security in Depth: New Security Features. Chromium Blog. Архів оригіналу за 2011-08-13. Процитовано 2010-11-19.
- ↑ Sid Stamm (August 26, 2010). HTTP Strict Transport Security has landed!. Архів оригіналу за 2012-07-04. Процитовано 2010-11-19.
- ↑ Giorgio (23 сентября 2009). Strict Transport Security in NoScript. Архів оригіналу за 2012-07-04. Процитовано 2010-11-19.
- ↑ Preloaded HSTS sites / 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:.