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 Архівовано 4 March 2016[Дата не збігається] у en:Wayback Machine. / 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 (англ.)
Отримано з https://uk.wikipedia.org/w/index.php?title=HSTS&oldid=24468650