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]

  1. Автоматично автономно перетворювати всі http-посилання на даний сайт в https-посилання. (Наприклад, замість http://uk.wikipedia.org/wiki/HSTS браузер буде використовувати https://uk.wikipedia.org/wiki/HSTS перетворення станеться до реального звернення до сервера.)
  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, однак такий підхід погано масштабується.

Станом на кінець 2014 року, в статичному списку знаходилося більше тисячі доменів, з них близько чверті — домени Google[10].

Використання

Сторінка налагодження HSTS і HPKP[en] в браузері Chromium для сайту en.wikipedia.org (до внесення у список HSTS preload, динамічний HSTS; HPKP не застосовується).

Дивись також

Примітки

  1. ↑ HTTP Strict Transport Security. Mozilla Developer Network. Архів оригіналу за 18 березня 2014. Процитовано 12 червня 2015.
  2. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 5. HSTS Mechanism Overview. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 21 листопада 2012.
  3. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). Section 12.1. No User Recourse. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 30 червня 2014.
  4. ↑ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). 2.3. Threat Model. RFC 6797. IETF. Архів оригіналу за 26 лютого 2020. Процитовано 21 листопада 2012.
  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. ↑ HSTS Preloading. Архів оригіналу за 3 квітня 2018. Процитовано 3 квітня 2018.
  9. ↑ 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 (26 січня 2010). Security in Depth: New Security Features. Chromium Blog. Архів оригіналу за 13 серпня 2011. Процитовано 19 листопада 2010.
  12. ↑ Sid Stamm (26 серпня 2010). HTTP Strict Transport Security has landed!. Архів оригіналу за 4 липня 2012. Процитовано 19 листопада 2010.
  13. ↑ Giorgio (23 сентября 2009). Strict Transport Security in NoScript. Архів оригіналу за 4 липня 2012. Процитовано 19 листопада 2010.
  14. ↑ Preloaded HSTS sites [Архівовано 18 лютого 2020 у Wayback Machine.] / Chromium

Посилання