HSTS
HSTS (скор. від англ. HTTP Strict Transport Security) — механізм, який примусово задіює захищене з'єднання через протокол HTTPS. Ця політика безпеки дозволяє відразу ж встановлювати безпечне з'єднання замість використання HTTP-протоколу. Механізм використовує особливий заголовок Strict-Transport-Security
для примусового використання браузером протоколу HTTPS навіть у разі переходу по посиланнях з явним зазначенням протоколу HTTP (http://). Механізм специфікований в [rfc:6797 RFC6797] в листопаді 2012 року.
HSTS допомагає запобігти частині атак, спрямованих на перехоплення з'єднання між користувачем і вебсайтом, зокрема атаку з пониженням ступеня захисту і крадіжку реп'яшків.
Додатковий захист 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].
Використання
![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Chromium_HSTS_settings_screenshot.png/220px-Chromium_HSTS_settings_screenshot.png)
- На клієнтській стороні
- Chromium 4 і всі браузери на його основі[11].
- Firefox 4[12]
- NoScript[13]
- На стороні сайту (всі перераховані включені в HSTS preload list):[14]
Дивись також
Примітки
- ↑ 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:10.14722/ndss.2015.23162.
- п
- о
- р
- Transport Layer Security / Secure Sockets Layer (TLS/SSL)
- Datagram Transport Layer Security[en] (DTLS)
- Server Name Indication (SNI)
- Application-Layer Protocol Negotiation (ALPN)
- DANE[en] (DANE)
- CAA[en] (CAA)
- HTTPS
- HTTP Strict Transport Security (HSTS)
- HTTP Public Key Pinning[en] (HPKP)
- OCSP stapling
- Perfect forward secrecy
- StartTLS
публічних ключів
- Automated Certificate Management Environment (ACME)
- Certificate authority (CA)
- CA/Browser Forum[en]
- Політика сертифікації[en]
- Список відкликаних сертифікатів (CRL)
- Domain-validated certificate[en] (DV)
- Extended Validation Certificate[en] (EV)
- Online Certificate Status Protocol (OCSP)
- Цифровий сертифікат
- Криптографія з відкритим ключем
- Інфраструктура відкритих ключів (PKI)
- Кореневий сертифікат
- Самопідписаний сертифікат[en]
- Domain Name System Security Extensions (DNSSEC)
- Internet Protocol Security (IPsec)
- Secure Shell (SSH)
- Експорт криптографії зі Сполучених Штатів Америки[en]
- Server-Gated Cryptography[en]
- Прозорість сертифікації[en]
- Convergence[en]
- HTTPS Everywhere
- Perspectives Project
Теорія |
|
---|---|
Шифр |
|
Протокол | |
Імплементація |
|