HTTPS

HTTPS (zkr. z angličtiny  HyperText Transfer Protocol Secure ) je rozšířením protokolu HTTP pro podporu šifrování za účelem zvýšení bezpečnosti. Data v protokolu HTTPS jsou přenášena prostřednictvím kryptografických protokolů TLS nebo SSL , jejichž podpora byla ukončena v roce 2015 [1] . Na rozdíl od HTTP s TCP portem 80 má HTTPS výchozí port TCP 443 [2] .

Protokol byl vyvinut společností Netscape Communications pro prohlížeč Netscape Navigator v roce 1994 [3] .

Jak to funguje

HTTPS není samostatný protokol. Jedná se o prostý HTTP běžící přes šifrované transportní mechanismy SSL a TLS [4] . Poskytuje ochranu proti útokům sniffer a útokům typu man-in-the-middle za předpokladu, že jsou použity šifrovací nástroje a certifikát serveru je ověřený a důvěryhodný [5] .

Ve výchozím nastavení HTTPS URL používá TCP port 443 (pro nezabezpečený HTTP - 80) [ 2] . Chcete-li připravit webový server pro zpracování připojení https, musí správce získat a nainstalovat certifikát veřejného a soukromého klíče pro tento webový server v systému. TLS používá jak schéma asymetrického šifrování (pro generování sdíleného tajného klíče), tak schéma symetrického šifrování (pro výměnu dat zašifrovaných sdíleným klíčem). Certifikát veřejného klíče potvrzuje, že daný veřejný klíč patří vlastníkovi webu. Certifikát veřejného klíče a samotný veřejný klíč jsou odeslány klientovi při navázání spojení; soukromý klíč slouží k dešifrování zpráv od klienta [6] .

Takový certifikát je možné vytvořit bez kontaktování certifikační autority . Takové certifikáty jsou podepsány stejným certifikátem a nazývají se self -signed ( self-signed ). Bez ověření certifikátu jiným způsobem (jako je volání vlastníka a kontrola kontrolního součtu certifikátu) je toto použití HTTPS náchylné k útoku typu man-in-the-mid [7] .

Tento systém lze také použít pro autentizaci klientů, aby bylo zajištěno, že k serveru budou mít přístup pouze oprávnění uživatelé . Za tímto účelem správce obvykle vytvoří certifikáty pro každého uživatele a nahraje je do prohlížeče každého uživatele. Budou také akceptovány všechny certifikáty podepsané organizacemi, kterým server důvěřuje. Takový certifikát obvykle obsahuje jméno a e-mailovou adresu oprávněného uživatele, které jsou kontrolovány při každém připojení za účelem ověření identity uživatele bez zadání hesla [8] .

HTTPS používá pro šifrování délku klíče 40, 56, 128 nebo 256 bitů. Některé starší verze prohlížečů používají 40bitovou délku klíče (příkladem jsou verze IE starší než 4.0) kvůli omezením exportu ve Spojených státech. Délka klíče 40 bitů není bezpečná. Mnoho moderních webových stránek vyžaduje použití nových verzí prohlížečů, které podporují 128bitové šifrování, aby byla zajištěna dostatečná úroveň zabezpečení. Šifrování s délkou klíče 128 bitů značně ztěžuje uhodnutí hesel a přístup k osobním informacím [6] .

Tradičně může na jedné IP adrese běžet pouze jeden web HTTPS. Více webů HTTPS s různými certifikáty používá rozšíření TLS s názvem Server Name Indication (SNI) [9] .

K 17. červenci 2017 používá HTTPS ve výchozím nastavení 22,67 % z 1 000 000 nejlepších webů Alexa [10] . HTTPS využívá 4,04 % z celkového počtu registrovaných ruských domén [11] .

HTTPS autentizace

Identifikace serveru

Požadavky HTTP/ TLS jsou generovány dereferencováním URI , takže klient zná název hostitele. Na začátku komunikace server odešle klientovi svůj certifikát, aby jej klient identifikoval. Tím se zabrání útoku typu man-in-the-middle. Certifikát určuje URI serveru. Vyjednávání názvu hostitele a údajů uvedených v certifikátu probíhá v souladu s protokolem RFC2459 [12] .

Pokud se název serveru neshoduje s názvem uvedeným v certifikátu, uživatelské programy, jako jsou prohlížeče, to uživateli oznámí. Prohlížeče v zásadě dávají uživateli na výběr, zda bude pokračovat v nezabezpečeném připojení nebo jej ukončit [13] .

Identifikace klienta

Server obvykle nemá dostatečné informace o klientovi, aby jej identifikoval. Pro zvýšení bezpečnosti spojení se však používá tzv. obousměrná autentizace. V tomto případě si server po potvrzení certifikátu klientem vyžádá i certifikát. Schéma autentizace klienta je tedy podobné autentizaci serveru [14] .

Chyby zabezpečení HTTPS

Sdílení HTTP a HTTPS

Když weby používají smíšené funkce HTTP a HTTPS, může to mít za následek informační hrozbu pro uživatele. Pokud se například hlavní stránky webu načítají pomocí HTTPS a CSS a JavaScript se načítají přes HTTP, pak může útočník v době načítání načíst svůj kód a získat data HTML stránky. Mnoho webů navzdory těmto zranitelnostem stahuje obsah prostřednictvím služeb třetích stran, které nepodporují HTTPS. Mechanismus HSTS takovým zranitelnostem brání tím, že vynucuje použití připojení HTTPS i tam, kde se standardně používá HTTP [15] .

Útoky pomocí analýzy provozu

V HTTPS byly objeveny chyby zabezpečení související s analýzou provozu. Útok na sledování provozu je typ útoku, který odvozuje vlastnosti zabezpečených dat kanálu měřením velikosti provozu a času potřebného k odeslání zpráv. Analýza provozu je možná, protože šifrování SSL/TLS mění obsah provozu, ale má minimální dopad na velikost a dobu přenosu provozu. V květnu 2010 výzkumníci z Microsoft Research a Indiana University zjistili, že podrobná a citlivá uživatelská data lze odvodit ze sekundárních dat, jako jsou velikosti paketů. Analyzátor návštěvnosti dokázal získat lékařskou historii uživatele, užívané léky a transakce provedené uživatelem, údaje o rodinných příjmech atd. To vše se podařilo i přes použití HTTPS v několika moderních webových aplikacích v oblasti zdravotnictví, daní a další [16] .

Útok makléře

Útok „man-in-the-middle“ využívá toho, že server HTTPS odešle certifikát veřejného klíče do prohlížeče . Pokud tento certifikát není důvěryhodný, bude přenosový kanál zranitelný vůči útoku útočníka. Tento útok nahradí původní certifikát ověřující HTTPS server upraveným certifikátem. Útok je úspěšný, pokud uživatel zanedbá dvojitou kontrolu certifikátu, když prohlížeč odešle varování. To je běžné zejména mezi uživateli, kteří se často setkávají s certifikáty s vlastním podpisem při přístupu na stránky v rámci sítě soukromé organizace [17] .

Na Obr. 1 ukazuje situaci, kdy je útočník bránou mezi klientem provádějícím zabezpečenou transakci a serverem. Veškerý klientský provoz tak prochází přes útočníka a ten jej může přesměrovat dle svého uvážení. Zde jsou provedeny následující kroky:

1. Útočník se vloží mezi klient a server
2. Předá všechny zprávy z klienta na server beze změny
3. Zachycování zpráv ze serveru odeslaných na výchozí bránu
4. Vytvoření certifikátu s vlastním podpisem a jeho nahrazení certifikátem serveru
5. Odeslání falešného certifikátu klientovi
6. Když klient ověří certifikát, vytvoří se zabezpečené spojení: mezi útočníkem a serverem a další mezi útočníkem a klientem.

V důsledku takového útoku si klient a server myslí, že navazují zabezpečené spojení, ale útočník má nyní také soukromý klíč a může dešifrovat jakoukoli zprávu v kanálu [17] .

Viz také

• SSL
• OpenSSL
• TLS
• SSH
• HSTS
• SPDY
• SCTP
• Pojďme šifrovat

Poznámky

1. ↑ Jaroslav Rjabov. SSL certifikáty jsou různé . Kaspersky Daily (24. dubna 2018). „[SSL] měl několik verzí, ale všechny byly v určitém okamžiku kritizovány kvůli přítomnosti bezpečnostních problémů. V důsledku toho byla vydána verze, která se nyní používá - byla přejmenována na TLS (Transport Layer Security). Název SSL se však uchytil lépe a nová verze protokolu se tak dodnes často nazývá. Získáno 19. března 2020. Archivováno z originálu dne 14. dubna 2020. (neurčitý)
2. ↑ 1 2 E. Rescorla. HTTP přes  TLS . tools.ietf.org. Získáno 25. prosince 2017. Archivováno z originálu 31. října 2018.
3. ↑ Zdi, Coline. Vestavěný software  (neopr.) . - Newnes, 2005. - S. 344. - ISBN 0-7506-7954-9 . Archivováno 9. února 2019 na Wayback Machine
4. ↑ E. Rescorla. HTTP přes  TLS . tools.ietf.org. Získáno 25. prosince 2017. Archivováno z originálu 31. října 2018.
5. ↑ E. Rescorla. HTTP přes  TLS . tools.ietf.org. Získáno 25. prosince 2017. Archivováno z originálu 31. října 2018.
6. ↑ 1 2 Tim Dierks <[email protected]>. Protokol TLS (Transport Layer Security) verze  1.2 . tools.ietf.org. Datum přístupu: 25. prosince 2017. Archivováno z originálu 24. prosince 2017.
7. ↑ E. Rescorla. HTTP přes  TLS . tools.ietf.org. Získáno 25. prosince 2017. Archivováno z originálu 31. října 2018.
8. ↑ Aboba, Bernard, Simon, Dan. PPP EAP TLS autentizační  protokol . buildbot.tools.ietf.org. Získáno 25. prosince 2017. Archivováno z originálu 1. října 2020.
9. ↑ Shbair et al, 2015 , pp. 990–995.
10. ↑ Statistiky používání HTTPS na top webech (downlink) . statoperator.com. Získáno 28. června 2016. Archivováno z originálu 9. února 2019. (neurčitý) 
11. ↑ Statistiky ruského internetu runfo.ru . www.runfo.ru Datum přístupu: 16. února 2017. Archivováno z originálu 17. února 2017. (Ruština)
12. ↑ Solo, David, Housley, Russell, Ford, Warwick. Certifikát a profil CRL  . tools.ietf.org. Získáno 22. prosince 2017. Archivováno z originálu 7. července 2017.
13. ↑ E. Rescorla. HTTP přes  TLS . tools.ietf.org. Získáno 22. prosince 2017. Archivováno z originálu 31. října 2018.
14. ↑ Tim Dierks <[email protected]>. Protokol TLS (Transport Layer Security) verze  1.2 . tools.ietf.org. Datum přístupu: 22. prosince 2017. Archivováno z originálu 24. prosince 2017.
15. ↑ Jak správně nasadit HTTPS  , Electronic Frontier Foundation (  15. listopadu 2010). Archivováno z originálu 10. října 2018. Staženo 23. prosince 2017.
16. ↑ Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Úniky postranních kanálů ve webových aplikacích: dnes realita, zítra výzva  //  Výzkum společnosti Microsoft. — 2010-05-01. Archivováno z originálu 16. března 2022.
17. ↑ 12 Callegati a kol., 2009 , str. 78.

Literatura

• Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang. Úniky postranních kanálů ve webových aplikacích: dnes realita, zítra výzva  //  Výzkum společnosti Microsoft. — 2010-05-01.
• F. Callegati, W. Cerroni, M. Ramilli. Man-in-the-Middle Attack na protokol HTTPS  // IEEE Security Privacy. - 2009. - Leden ( díl 7 , číslo 1 ). - S. 78-81 . — ISSN 1540-7993 . - doi : 10.1109/MSP.2009.12 .
• W. M. Shbair, T. Cholez, A. Goichot, I. Chrisment. Efektivní obcházení filtrování HTTPS na bázi SNI  // Mezinárodní symposium IFIP/IEEE 2015 o integrované správě sítě (IM). - 2015. - Květen. - doi : 10.1109/INM.2015.7140423 .

Slovníky a encyklopedie	Skvělý norský