HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) je v informatice bezpečnostní mechanismus, který chrání síťovou komunikaci mezi webovým prohlížečem a webovým serverem před downgrade útoky a zjednodušuje ochranu proti únosu spojení (tzv. cookie hijacking). Mechanismus umožňuje, aby webový server vynutil v prohlížeči komunikaci pouze pomocí šifrovaného HTTPS připojení a vyloučil tím přenos dat nezabezpečeným HTTP protokolem. HSTS definuje RFC 6797. Webový server aktivuje HSTS pomocí HTTP hlavičky Strict-Transport-Security,[1] která svou hodnotou definuje časový úsek, po který může prohlížeč přistupovat k serveru výhradně zabezpečeně.

Historie

editovat

Specifikace HSTS byla schválena 2. října 2012 a následně publikována 19. listopadu 2012 jako RFC 6797. Původně autoři odeslali návrh jako Internet-Draft 17. června 2010. V rámci diskuze nad návrhem bylo jméno změněno ze „Strict Transport Security“ (STS) na „HTTP Strict Transport Security“ (HSTS). Důvodem pro změnu bylo, že jde o specifickou záležitost HTTP protokolu[2] (název v HTTP hlavičce zůstal Strict-Transport-Security).

HSTS mechanismus

editovat

Server implementuje HSTS politiku tím, že odesílá hlavičku přes HTTPS připojení (HSTS hlavičky odeslané pomocí HTTP jsou ignorovány).[3] Server může například odeslat hlavičku, která určí, že všechny budoucí dotazy na danou doménu budou používat jen HTTPS připojení po dobu jednoho roku: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Pokud webová aplikace[4] poskytne HSTS politiku user agentovi, agent se chová následovně:[5]

  1. Automaticky převede všechny nezabezpečené odkazy, které odkazují na webovou aplikaci, na zabezpečené. (http://example.com/some/page/ bude převedeno na https://example.com/some/page/ předtím, než přistoupí na server.)
  2. Pokud nemůže být navázáno zabezpečené připojení (např. pokud TLS certifikát je podepsaný sám sebou), zobrazí se chybová hláška a uživateli bude zamezen přístup do webové aplikace.[6]

HSTS pomáhá chránit webové aplikace proti některým pasivním (odposlechy) a aktivním síťovým útokům.[7] Díky HSTS mechanismu má útočník, který využívá man-in-the-middle útok, velmi sníženou šanci, že odchytí nějaké žádosti či požadavky odeslané mezi uživatelem a webovou aplikací.

Využití

editovat

Technologie HSTS dokáže odstranit problémy se SSL-stripping man-in-the-middle útokem, který byl poprvé publikován Moxie Marlinspikem v roce 2009 na BlackHat Federal talk pod názvem „New Tricks For Defeating SSL In Practice“.[8] SSL-stripping útoky (na SSL a TLS) transparentně převádějí zabezpečené HTTPS připojení na nezabezpečené HTTP připojení. Uživatel uvidí, že jeho připojení je nezabezpečené, ale v zásadě neví, zda by připojení mělo být zabezpečené nebo ne. Mnoho stránek nevyužívá TLS/SSL, proto není žádný způsob jak zjistit, zda je připojení v nezabezpečeném HTTP kvůli útoku nebo jen proto, že stránky nevyužívají TLS/SSL.

HSTS řeší tento problém[7] tak, že prohlížeči sdělí, že by připojení k serveru mělo vždy využívat TLS/SSL. HSTS hlavička může být útočníkem odstraněna, pokud uživatel na stránku přistupuje poprvé. Prohlížeče Google Chrome a Mozilla Firefox se snaží tomuto předcházet tak, že poskytuje předem načtený seznam HSTS sítí.[9][10] Toto řešení bohužel nelze použít pro všechny stránky v Internetu. Více níže v kapitole „Omezení“.

HSTS také pomáhá předcházet krádeži přihlašovacích HTTP cookies pomocí rozšířeného nástroje Firesheep (plugin pro Firefox).[11]

Jelikož je HSTS časově omezeno, je citlivý například na útoky, které posouvají systémový čas cílového počítače využitím falešných NTP paketů.

Omezení

editovat

Původní požadavek zůstává nechráněn proti aktivním útokům, pokud se použije nezabezpečený protokol (HTTP) nebo pokud URI pro původní požadavek byla získána přes nezabezpečený kanál.[12] To samé platí v případě, kdy poprvé přistupujeme na stránky po uplynutí doby stanovené HSTS politikou max-age (tato doba by měla být nastavena na několik dní nebo měsíců v závislosti na aktivitě a chování uživatele). Google Chrome a Mozilla Firefox řeší toto omezení pomocí „STS preloaded list“, což je seznam obsahující známé sítě, které podporují HSTS.[9][10] Tento seznam je distribuován s prohlížečem, díky čemuž využívá zabezpečené připojení pro sítě v seznamu již při prvním přístupu. Avšak, jak již bylo zmíněno, toto řešení nedokáže pokrýt všechny stránky na internetu. Možným řešením by mohlo být využití DNS záznamů pro deklarování HSTS politiky a přistupovat k nim zabezpečeně pomocí DNSSEC.

Ani využitím „STS preloaded list“ nemůže HSTS předcházet pokročilým útokům proti TLS jako je například BEAST nebo CRIME.

Podpora v prohlížečích

editovat

Důsledky nesprávného nastavení nebo opomenutí

editovat

Při nasazení HSTS je nutné udržovat platný certifikát, v opačném případě se webová stránka může stát nedostupnou. Poté, co kvůli neschválení rozpočtu USA muselo asi 800 000 zaměstnanců nastoupit dovolenou, do 21. ledna 2019 nebylo obnoveno přes 130 TLS certifikátů vládních webů, přičemž stránky, které jsou v seznamu STS preloaded list se tak staly úplně nedostupnými, protože v tomto případě prohlížeč neumožní přidání výjimky.[21][22]

Reference

editovat

V tomto článku byl použit překlad textu z článku HSTS na anglické Wikipedii.

  1. HODGES, Jeff, Jackson, Collin; Barth, Adam. Section 5.2. HSTS Policy [online]. IETF, Nov 2012 [cit. 2012-11-21]. Dostupné online. 
  2. Jeff Hodges. Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...) [online]. 30 June 2010 [cit. 2010-07-22]. Dostupné online. 
  3. https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
  4. NATIONS, Daniel. Web Applications: What is a Web Application? [online]. About.com [cit. 2012-11-21]. Dostupné online. 
  5. HODGES, Jeff, Jackson, Collin; Barth, Adam. Section 5. HSTS Mechanism Overview [online]. IETF, Nov 2012 [cit. 2012-11-21]. Dostupné online. 
  6. HODGES, Jeff, Jackson, Collin; Barth, Adam. Section 12.1. No User Recourse [online]. IETF, Nov 2012 [cit. 2014-06-30]. Dostupné online. 
  7. a b HODGES, Jeff, Jackson, Collin; Barth, Adam. 2.3. Threat Model [online]. IETF, Nov 2012 [cit. 2012-11-21]. Dostupné online. 
  8. New Tricks For Defeating SSL In Practice. blackhat.com. Dostupné online. 
  9. a b Adam Langley. Strict Transport Security [online]. 8 July 2010 [cit. 2010-07-22]. Dostupné online. 
  10. a b c David Keeler. Preloading HSTS [online]. 1 November 2012 [cit. 2014-02-06]. Dostupné online. 
  11. Jeff Hodges. Firesheep and HSTS (HTTP Strict Transport Security) [online]. 31 October 2010 [cit. 2011-03-08]. Dostupné online. 
  12. HODGES, Jeff, Jackson, Collin; Barth, Adam. Section 14.6. Bootstrap MITM Vulnerability [online]. IETF, Nov 2012 [cit. 2012-11-21]. Dostupné online. 
  13. The Chromium Developers. Strict Transport Security - The Chromium Projects [online]. 17 November 2010 [cit. 2010-11-17]. Dostupné online. 
  14. Jeff Hodges. fyi: Strict Transport Security specification [online]. 18 September 2009 [cit. 2009-11-19]. Dostupné online. 
  15. HTTP Strict Transport Security [online]. [cit. 2011-03-17]. Dostupné online. 
  16. Opera Software ASA. Web specifications support in Opera Presto 2.10 [online]. 23 April 2012 [cit. 2012-05-08]. Dostupné online. 
  17. @agl__ (Adam Langley). Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers. [online]. [cit. 2013-12-20]. Dostupné online. 
  18. ČÍŽEK, Jakub. IE11 je po letech zase o kus bezpečnější. Umí HSTS. zive.cz [online]. 2015-06-12 [cit. 2015-06-12]. Dostupné online. 
  19. Low adoption rate of HSTS website security mechanism is worrying, EFF says [online]. April 8, 2014 [cit. 2014-04-14]. Dostupné online. 
  20. Internet Explorer Web Platform Status and Roadmap [online]. [cit. 2014-04-14]. Dostupné v archivu pořízeném dne 2015-06-29. 
  21. Postřehy z bezpečnosti: HSTS v časech sporů o rozpočet. root.cz [online]. 21. 1. 2019. Dostupné online. ISSN 1212-8309. 
  22. NOHE, Patrick. More websites breaking as certificates expire during government shutdown. Hashed Out [online]. January 18, 2019. Dostupné online.