Přísné zabezpečení přenosu HTTP - HTTP Strict Transport Security

Přísné zabezpečení přenosu HTTP (HSTS) je zabezpečení webu politický mechanismus, který pomáhá chránit webové stránky proti útoky typu man-in-the-middle jako útoky na downgrade protokolu[1] a únos cookie. To umožňuje webové servery deklarovat to internetové prohlížeče (nebo jiné vyhovující uživatelské agenty ) by s ním měl automaticky komunikovat pouze pomocí HTTPS spojení, která poskytují Zabezpečení transportní vrstvy (TLS / SSL), na rozdíl od nezabezpečených HTTP použit samostatně. HSTS je IETF standardy sledovat protokol a je specifikován v RFC 6797.

Zásady HSTS jsou serverem komunikovány s agentem uživatele prostřednictvím odpovědi HTTPS záhlaví pole s názvem „Přísná dopravní bezpečnost".[1] Zásady HSTS specifikují časové období, během kterého by měl uživatelský agent přistupovat na server pouze zabezpečeným způsobem.[2] Webové stránky využívající HSTS často nepřijímají prostý text HTTP, ať už odmítnutím připojení přes HTTP, nebo systematickým přesměrováním uživatelů na HTTPS (i když to specifikace nevyžaduje). Důsledkem toho je, že uživatelský agent, který není schopen provádět TLS, se nebude moci připojit k webu.

Ochrana platí pouze poté, co uživatel alespoň jednou web navštívil, a způsob, jakým tato ochrana funguje, je ten, že uživatel, který zadá nebo vybere adresu URL webu, který určuje HTTP, se automaticky upgraduje na HTTPS, aniž by zadal požadavek HTTP, který zabrání výskytu útoku typu man-in-the-middle HTTP.

Historie specifikací

Specifikace HSTS byla zveřejněna jako RFC 6797 dne 19. listopadu 2012 poté, co byl dne 2. října 2012 schválen IESG pro publikaci jako Navrhovaný standard RFC.[3]Autoři jej původně předložili jako Koncept internetu dne 17. června 2010. S převodem na internetový koncept byl název specifikace změněn z „Strict Transport Security“ (STS) na „HTTP Strict Transport Security“, protože specifikace se vztahuje pouze na HTTP.[4] Pole záhlaví odpovědi HTTP definované ve specifikaci HSTS však zůstává pojmenováno „Strict-Transport-Security“.

Poslední takzvaná „komunitní verze“ tehdy pojmenované specifikace „STS“ byla zveřejněna 18. prosince 2009 s revizemi založenými na zpětné vazbě komunity.[5]

Původní návrh specifikace od Jeffa Hodgese z PayPal, Collin Jackson a Adam Barth byly zveřejněny dne 18. září 2009.[6]

Specifikace HSTS je založena na původní práci Jacksona a Bartha popsané v jejich příspěvku „ForceHTTPS: Ochrana vysoce zabezpečených webových stránek před útoky v síti“.[7]

HSTS je navíc realizací jednoho aspektu celkové vize zlepšování zabezpečení webu, kterou předložili Jeff Hodges a Andy Steingruebl ve svém příspěvku z roku 2010 Potřeba koherentního rámce politiky zabezpečení webu.[8]

Přehled mechanismu HSTS

Server implementuje zásadu HSTS zadáním záhlaví přes připojení HTTPS (záhlaví HSTS přes HTTP jsou ignorována).[1] Například server může odeslat záhlaví tak, aby budoucí požadavky na doménu pro příští rok (maximální věk je zadán v sekundách; 31 536 000 se rovná jednomu přestupnému roku) používají pouze HTTPS: Strict-Transport-Security: max-age = 31536000.

Když webová aplikace vydává zásady HSTS agentům uživatelů, chovají se odpovídající agenti uživatelů následujícím způsobem (RFC 6797):[9]

  1. Automaticky přeměňte všechny nezabezpečené odkazy odkazující na webovou aplikaci na zabezpečené odkazy (např. http://example.com/některé/stránka/ bude upraven na https://example.com/některé/stránka/ před přístup na server).
  2. Pokud nelze zajistit zabezpečení připojení (např. Server TLS osvědčení není důvěryhodný), uživatelský agent musí ukončit připojení (RFC 6797 část 8.4, Chyby v zabezpečeném transportním zařízení) a neměla by uživateli umožňovat přístup k webové aplikaci (část 12.1, Zákazník).

Zásady HSTS pomáhají chránit uživatele webových aplikací před některými pasivními (odposlouchávání ) a aktivní síť útoky.[10] A man-in-the-middle útočník má výrazně sníženou schopnost zachytit požadavky a odpovědi mezi uživatelem a serverem webové aplikace, zatímco prohlížeč uživatele má pro tuto webovou aplikaci platné zásady HSTS.

Použitelnost

Nejdůležitější bezpečnostní chybou, kterou může HSTS opravit, je odizolování SSL útoky typu man-in-the-middle, poprvé veřejně představen Moxie Marlinspike ve svém rozhovoru BlackHat Federal 2009 „Nové triky pro porážku SSL v praxi“.[11][12] SSL (a TLS ) odstranění útoku funguje transparentním převedením zabezpečeného HTTPS připojení na jednoduché připojení HTTP. Uživatel vidí, že připojení není bezpečné, ale zásadně neexistuje způsob, jak zjistit, zda je připojení by měl být v bezpečí. V době přednášky Marlinspike mnoho webů nepoužívalo TLS / SSL, proto neexistoval způsob, jak zjistit (bez předchozí znalosti), zda použití prostého protokolu HTTP bylo způsobeno útokem, nebo jednoduše proto, že web neimplementoval TLS / SSL. Během procesu přechodu na nižší verzi se uživateli navíc nezobrazí žádná varování, takže útok je celkem jemný pro všechny kromě těch nejbezpečnějších. Nástroj sslstrip společnosti Marlinspike útok plně automatizuje.[Citace je zapotřebí ]

HSTS tento problém řeší[10] informováním prohlížeče, že připojení k webu by mělo vždy používat TLS / SSL. Pokud se jedná o první návštěvu uživatele, může útočník odstranit záhlaví HSTS. Google Chrome, Mozilla Firefox, internet Explorer a Microsoft Edge pokusit se tento problém omezit zahrnutím „předem načteného“ seznamu webů HSTS.[13][14][15]Toto řešení bohužel nemůže zahrnovat všechny webové stránky na internetu. Vidět omezení níže.

HSTS může také pomoci zabránit tomu, aby někdo měl odcizení přihlašovacích údajů pro webové stránky založené na cookies široce dostupnými nástroji, jako je Firesheep.[16]

Protože HSTS je časově omezený, je citlivý na útoky zahrnující posunutí počítačového času oběti, např. pomocí false NTP balíčky.[17]

Omezení

Počáteční požadavek zůstává nechráněný před aktivními útoky, pokud používá nezabezpečený protokol, jako je prostý HTTP, nebo pokud URI pro počáteční požadavek byl získán přes nezabezpečený kanál.[18] Totéž platí pro první požadavek po období aktivity uvedeném v inzerovaných zásadách HSTS maximální věk (weby by měly nastavit období několika dní nebo měsíců v závislosti na aktivitě a chování uživatelů). Google Chrome, Mozilla Firefox a internet Explorer /Microsoft Edge řešit toto omezení implementací "předem zavedeného seznamu HSTS", což je seznam, který obsahuje známé weby podporující HSTS.[19][13][14][15] Tento seznam je distribuován s prohlížečem, takže používá HTTPS i pro počáteční požadavek na uvedené weby. Jak již bylo zmíněno dříve, tyto předem načtené seznamy nelze škálovat tak, aby pokrývaly celý web. Potenciálního řešení lze dosáhnout použitím DNS záznamy deklarovat zásady HSTS a zabezpečený přístup k nim prostřednictvím DNSSEC, volitelně s otisky certifikátů k zajištění platnosti (což vyžaduje spuštění ověřovacího resolveru, aby se zabránilo) poslední míle problémy).[20]

Junade Ali poznamenala, že HSTS je neúčinný proti používání falešných domén; pomocí útoků založených na DNS je možné, aby zachytávač typu Man-in-the-Middle sloužil provozu z umělé domény, která není na seznamu HSTS Preload,[21] to je možné díky DNS Spoofing Attacks,[22] nebo jednoduše název domény, který se zavádějícím způsobem podobá skutečnému názvu domény, jako je www.example.org namísto www.example.com.

Ani s "předem načteným seznamem HSTS" nemůže HSTS zabránit pokročilým útokům proti samotnému TLS, jako je BESTIE nebo ZLOČIN útoky zavedené Julianem Rizzem a Thai Duongem. Samotné útoky na TLS jsou ortogonální k prosazování zásad HSTS. Ani to nemůže chránit před útoky na server - pokud to někdo kompromituje, bude šťastně poskytovat jakýkoli obsah přes TLS.[Citace je zapotřebí ]

Vidět RFC  6797 pro diskusi o celkových bezpečnostních úvahách HSTS.

Problémy s ochranou soukromí

HSTS lze použít k téměř nesmazatelnému označení hostujících prohlížečů pomocí obnovitelných identifikačních údajů (supercookies ), které mohou přetrvávat v prohlížeči i mimo něj “inkognito "režimy ochrany osobních údajů. Vytvořením webové stránky, která provádí více požadavků HTTP na vybrané domény, například pokud se použije dvacet požadavků prohlížeče na dvacet různých domén, lze teoreticky rozlišit více než jeden milion návštěvníků (220) kvůli výsledným žádostem přicházejícím přes HTTP vs. HTTPS; druhé jsou dříve zaznamenané binární „bity“ vytvořené dříve prostřednictvím hlaviček HSTS.[23]

Podpora prohlížeče

Stránka nastavení pro HTTPS Strict Transport Security v rámci Chromium 45, zobrazující stav bezpečnostní politiky pro doménu „en.wikipedia.org“.

Osvědčené postupy nasazení

V závislosti na skutečném nasazení existují určité hrozby (např. Útoky na vkládání souborů cookie), kterým se lze vyhnout dodržováním osvědčených postupů.

  • Hostitelé HSTS by měli deklarovat zásady HSTS na svém názvu domény nejvyšší úrovně. Například hostitel HSTS na adrese https://sub.example.com by měl také odpovědět pomocí hlavičky HSTS na adrese https://example.com. Záhlaví by mělo specifikovat includeSubDomains směrnice.[31]
  • Kromě nasazení HSTS by hostitel pro https://www.example.com měl obsahovat požadavek na prostředek z https://example.com, aby se ujistil, že je nastaven HSTS pro nadřazenou doménu a chrání uživatele před potenciálním útoky vkládání souborů cookie prováděné MITM, který by vložil odkaz na nadřazenou doménu (nebo dokonce http://nonexistentpeer.example.com), na který by pak útočník odpověděl.[32]

Viz také

Reference

  1. ^ A b C d „Strict-Transport-Security“. Webové dokumenty MDN. Mozilla. Citováno 31. ledna 2018.
  2. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (listopad 2012). „Zásady HSTS“. Zabezpečení HTTP Strict Transport (HSTS). IETF. doi:10.17487 / RFC6797. RFC 6797. Citováno 31. ledna 2018.
  3. ^ „[websec] Action Protocol: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2. října 2012. Citováno 2. října 2012.
  4. ^ Jeff Hodges (30. června 2010). „Re: [HASMAT] přezdívka„ STS “(byl: IETF BoF @ IETF-78 Maastricht: HASMAT ...)“. Citováno 22. července 2010.
  5. ^ „Přísné zabezpečení dopravy -06“. 18. prosince 2009. Citováno 23. prosince 2009.
  6. ^ „Přísné zabezpečení dopravy -05“. 18. září 2009. Citováno 19. listopadu 2009.
  7. ^ „ForceHTTPS: Ochrana vysoce zabezpečeného webu před síťovými útoky“. Dubna 2008. Citováno 19. listopadu 2009.
  8. ^ Hodges, Jeff; Steinguebl, Andy (29. října 2010). „Potřeba koherentního rámce politiky zabezpečení webu“. Citováno 21. listopadu 2012.
  9. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (listopad 2012). "Oddíl 5. Přehled mechanismu HSTS". RFC 6797. IETF. Citováno 21. listopadu 2012.
  10. ^ A b Hodges, Jeff; Jackson, Collin; Barth, Adam (listopad 2012). "2.3. Model ohrožení". RFC 6797. IETF. Citováno 21. listopadu 2012.
  11. ^ „Nové triky, jak v praxi porazit SSL“ (PDF). Citovat deník vyžaduje | deník = (Pomoc)
  12. ^ Porážka SSL pomocí Sslstrip na Youtube
  13. ^ A b Adam Langley (8. července 2010). „Přísná bezpečnost dopravy“. Chromové projekty. Citováno 22. července 2010.
  14. ^ A b C David Keeler (1. listopadu 2012). „Preloading HSTS“. Blog zabezpečení Mozilla. Citováno 6. února 2014.
  15. ^ A b Bell, Mike; Walp, David (16. února 2015). „HTTP Strict Transport Security přichází do aplikace Internet Explorer“. Citováno 16. února 2015.
  16. ^ Jeff Hodges (31. října 2010). „Firesheep a HSTS (HTTP Strict Transport Security)“. Citováno 8. března 2011.
  17. ^ Jose Selvi (17. října 2014). „Obcházení přísného zabezpečení přenosu HTTP“ (PDF). Citováno 22. října 2014.
  18. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (listopad 2012). „Oddíl 14.6. Zranitelnost Bootstrap MITM“. RFC 6797. IETF. Citováno 21. listopadu 2012.
  19. ^ „Chromium HSTS Preloaded list“. cs.chromium.org. Citováno 10. července 2019.
  20. ^ Butcher, Simon (11. září 2011). „Přísné zabezpečení přenosu HTTP“. Citováno 27. března 2012.
  21. ^ Ali, Junade (20. října 2017). „Provádění a prevence odizolování SSL: prostý anglický základ“. Cloudflare Blog.
  22. ^ Maksutov, A. A .; Cherepanov, I. A .; Alekseev, M. S. (2017). 2017 Sibiřské symposium o datové vědě a inženýrství (SSDSE). str. 84–87. doi:10.1109 / SSDSE.2017.8071970. ISBN  978-1-5386-1593-5. S2CID  44866769.
  23. ^ „Super cookie HSTS vás nutí zvolit:„ soukromí nebo zabezpečení? “-“. sophos.com. Citováno 1. prosince 2015.
  24. ^ Vývojáři chromu (17. listopadu 2010). „Přísná bezpečnost dopravy - chromové projekty“. Citováno 17. listopadu 2010.
  25. ^ Jeff Hodges (18. září 2009). "fyi: Přísná specifikace zabezpečení přenosu". Citováno 19. listopadu 2009.
  26. ^ Opera Software ASA (23. dubna 2012). „Podpora webových specifikací v aplikaci Opera Presto 2.10“. Citováno 8. května 2012.
  27. ^ @agl__ (Adam Langley ). "Potvrzeno. Viz ~ / Library / Cookies / HSTS.plist. Zahrnuje předpětí Chromu od určitého data a zpracovává záhlaví HSTS". na Twitteru. Citováno 20. prosince 2013.
  28. ^ „HTTP Strict Transport Security přichází do aplikace Internet Explorer 11 pro Windows 8.1 a Windows 7“. windows.com. Citováno 12. června 2015.
  29. ^ „Stav a plán webové platformy Internet Explorer“. Citováno 14. dubna 2014.
  30. ^ „Project Spartan and the Windows 10 January Preview Build - IEBlog“. Citováno 23. ledna 2015.
  31. ^ Hodges; et al. „HTTP Strict Transport Security (HSTS) 6.1.2“. ietf.org. Citováno 11. listopadu 2016.
  32. ^ „RFC 6797 - HTTP Strict Transport Security (HSTS)“. Nástroje IETF. Archivováno z původního dne 28. května 2019. Citováno 28. května 2019.

externí odkazy