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]

  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 не застосовується).

Дивись також[ред.ред. код]

  • HTTPS Everywhere

Примітки[ред.ред. код]

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

Посилання[ред.ред. код]

  • [rfc:6797 Специфікація HTTP Strict Transport Security (HSTS)] RFC 6797, листопад 2012 (англ.)