Robert Heaton

HTTPS je jednoduše standardní protokol HTTP pokrytý velkorysou vrstvou lahodného šifrování SSL/TLS. Pokud se něco strašlivě nepokazí (a to se může stát), zabraňuje lidem, jako je nechvalně proslulá Eve, prohlížet nebo upravovat požadavky, které tvoří vaše prohlížení; je to to, co udržuje vaše hesla, komunikaci a údaje o kreditních kartách v bezpečí na drátech mezi vaším počítačem a servery, kterým chcete tyto údaje poslat. Malý zelený visací zámek a písmena „https“ v adresním řádku sice neznamenají, že vy i prohlížená webová stránka stále nemáte dostatek lana, abyste se mohli pověsit jinam, ale alespoň vám pomáhají bezpečně komunikovat.

Co je HTTPS a k čemu slouží?

HTTPS přebírá dobře známý a srozumitelný protokol HTTP a jednoduše na něj vrství šifrovací vrstvu SSL/TLS (dále jen „SSL“). Servery a klienti mezi sebou stále hovoří přesně stejným protokolem HTTP, ale přes zabezpečené spojení SSL, které šifruje a dešifruje jejich požadavky a odpovědi. Vrstva SSL má dva hlavní účely:

• Ověření, že mluvíte přímo se serverem, se kterým si myslíte, že mluvíte
• Zajištění, že pouze server může číst to, co mu posíláte, a pouze vy můžete číst to, co posílá zpět

Skutečně chytrá část spočívá v tom, že kdokoli může zachytit každou zprávu, kterou si se serverem vyměníte, včetně těch, ve kterých se domlouváte na klíči a strategii šifrování, a přesto nebude schopen přečíst žádná skutečná data, která posíláte.

Jak se navazuje spojení SSL

Spojení SSL mezi klientem a serverem se navazuje pomocí handshake, jehož cíle jsou následující:

• Ujistit klienta, že hovoří se správným serverem (a případně i naopak)
• Aby se strany dohodly na „sadě šifer“, která zahrnuje šifrovací algoritmus, který budou používat pro výměnu dat
• Pro strany, aby se dohodly na všech potřebných klíčích pro tento algoritmus

Po navázání spojení mohou obě strany používat dohodnutý algoritmus a klíče k bezpečnému vzájemnému odesílání zpráv. Handshake rozdělíme do tří hlavních fází – Hello, Certificate Exchange a Key Exchange.

1. Hello – Handshake začíná odesláním zprávy ClientHello klientem. Ta obsahuje všechny informace, které server potřebuje k připojení ke klientovi prostřednictvím protokolu SSL, včetně různých sad šifer a maximální verze protokolu SSL, kterou podporuje. Server odpoví zprávou ServerHello, která obsahuje podobné informace požadované klientem, včetně rozhodnutí na základě klientových preferencí o tom, která sada šifer a verze protokolu SSL bude použita.

2. Výměna certifikátu – Nyní, když byl navázán kontakt, musí server prokázat klientovi svou totožnost. K tomu slouží jeho certifikát SSL, který je tak trochu jeho pasem. Certifikát SSL obsahuje různé údaje, včetně jména vlastníka, vlastnosti (např. domény), ke které je připojen, veřejného klíče certifikátu, digitálního podpisu a informace o datech platnosti certifikátu. Klient kontroluje, zda certifikátu buď implicitně důvěřuje, nebo zda je ověřen a důvěryhodný u jedné z několika certifikačních autorit, kterým rovněž implicitně důvěřuje. O tom se brzy dozvíte mnohem více. Všimněte si, že server může také požadovat certifikát k prokázání totožnosti klienta, ale to se obvykle děje pouze ve velmi citlivých aplikacích.

3. Výměna klíčů – Šifrování vlastních dat zpráv, které si klient a server vyměňují, se provede pomocí symetrického algoritmu, jehož přesná povaha byla dohodnuta již během fáze Hello. Symetrický algoritmus používá jediný klíč pro šifrování i dešifrování, na rozdíl od asymetrických algoritmů, které vyžadují dvojici veřejný/soukromý klíč. Obě strany se musí dohodnout na tomto jediném symetrickém klíči, což je proces, který se provádí bezpečně pomocí asymetrického šifrování a veřejných/soukromých klíčů serveru.

Klient vygeneruje náhodný klíč, který se použije pro hlavní, symetrický algoritmus. Zašifruje jej pomocí algoritmu, který byl rovněž dohodnut během fáze Hello, a veřejného klíče serveru (který se nachází v jeho certifikátu SSL). Tento zašifrovaný klíč odešle serveru, kde je dešifrován pomocí soukromého klíče serveru, a zajímavé části handshake jsou dokončeny. Strany jsou dostatečně spokojené s tím, že hovoří se správnou osobou, a tajně se dohodly na klíči pro symetrické šifrování dat, která se chystají navzájem poslat. Požadavky a odpovědi HTTP lze nyní odesílat tak, že se vytvoří zpráva v prostém textu a poté se zašifruje a odešle. Druhá strana je jediná, kdo ví, jak tuto zprávu dešifrovat, a tak útočníci typu Man In The Middle nemohou číst ani upravovat žádné požadavky, které mohou zachytit.

Certifikáty

Na nejzákladnější úrovni je certifikát SSL jednoduše textový soubor a každý, kdo má textový editor, jej může vytvořit. Ve skutečnosti můžete triviálně vytvořit certifikát, který bude tvrdit, že jste společnost Google Inc. a že ovládáte doménu gmail.com. Kdyby to byl celý příběh, pak by SSL byl vtip; ověření identity by v podstatě spočívalo v tom, že by se klient zeptal serveru: „Jste Google?“, server by odpověděl: „Ehm, ano, určitě, tady je kus papíru s nápisem ‚Jsem Google'“ a klient by řekl: „OK, skvělé, tady jsou všechna moje data“. Kouzlo, které zabraňuje této frašce, spočívá v digitálním podpisu, který umožňuje jedné straně ověřit, že kus papíru druhé strany je opravdu pravý.

Existují dva rozumné důvody, proč můžete certifikátu důvěřovat:

• Je-li na seznamu certifikátů, kterým implicitně důvěřujete
• Je-li schopen prokázat, že mu důvěřuje správce některého z certifikátů na výše uvedeném seznamu

První kritérium lze snadno ověřit. Váš prohlížeč má předinstalovaný seznam důvěryhodných certifikátů SSL od certifikačních autorit, který můžete zobrazit, přidat a odebrat. Tyto certifikáty jsou řízeny centralizovanou skupinou (teoreticky a obecně v praxi) mimořádně bezpečných, spolehlivých a důvěryhodných organizací, jako jsou Symantec, Comodo a GoDaddy. Pokud server předloží certifikát z tohoto seznamu, pak víte, že mu můžete důvěřovat.

Druhé kritérium je mnohem těžší. Pro server je snadné říci „ehm, jo, jmenuji se ehm, Microsoft, Symantecu věříte a ehm, oni mi naprosto důvěřují, takže je to v pohodě“. Trochu chytrý klient by pak mohl jít a zeptat se Symantecu: „Mám tady Microsoft, který říká, že mu věříte, je to pravda?“. Ale i když Symantec řekne „jo, my je známe, Microsoft je důvěryhodný“, stejně nevíte, jestli server, který se vydává za Microsoft, je skutečně Microsoft nebo něco mnohem horšího. Zde přicházejí na řadu digitální podpisy.

3.2 Digitální podpisy

Jak již bylo uvedeno, certifikáty SSL mají přidružený pár veřejný/soukromý klíč. Veřejný klíč je distribuován jako součást certifikátu a soukromý klíč je neuvěřitelně bezpečně střežen. Tento pár asymetrických klíčů se používá při předávání protokolu SSL k výměně dalšího klíče pro obě strany k symetrickému šifrování a dešifrování dat. Klient použije veřejný klíč serveru k zašifrování symetrického klíče a jeho bezpečnému odeslání na server a server použije svůj soukromý klíč k jeho dešifrování. Kdokoli může šifrovat pomocí veřejného klíče, ale pouze server může dešifrovat pomocí soukromého klíče.

Opačný případ je digitální podpis. Certifikát může být „podepsán“ jinou autoritou, čímž tato autorita fakticky prohlašuje: „Ověřili jsme, že správce tohoto certifikátu ovládá také vlastnost (doménu) uvedenou v certifikátu“. V tomto případě orgán použije svůj soukromý klíč k (obecně řečeno) zašifrování obsahu certifikátu a tento šifrovaný text je připojen k certifikátu jako jeho digitální podpis. Kdokoli může tento podpis dešifrovat pomocí veřejného klíče autority a ověřit, že výsledkem je očekávaná dešifrovaná hodnota. Ale pouze autorita může zašifrovat obsah pomocí soukromého klíče, a tak pouze autorita může v první řadě skutečně vytvořit platný podpis.

Pokud tedy přijde server, který tvrdí, že má certifikát pro Microsoft.com podepsaný společností Symantec (nebo jinou certifikační autoritou), váš prohlížeč mu nemusí věřit na slovo. Pokud je certifikát legální, společnost Symantec použila svůj (ultratajný) soukromý klíč k vygenerování digitálního podpisu certifikátu SSL serveru, a váš prohlížeč tak může použít svůj (ultraveřejný) veřejný klíč ke kontrole platnosti tohoto podpisu. Společnost Symantec podnikla kroky k zajištění toho, aby organizace, za kterou podepisuje, skutečně vlastnila Microsoft.com, a tak vzhledem k tomu, že váš klient důvěřuje společnosti Symantec, může si být jistý, že skutečně hovoří se společností Microsoft Inc.

3.3 Vlastní podpis

Všimněte si, že všechny certifikáty kořenové certifikační autority jsou „vlastní“, což znamená, že digitální podpis je generován pomocí vlastního soukromého klíče certifikátu. Na certifikátu kořenové certifikační autority není ze své podstaty nic zvláštního – pokud chcete, můžete si vygenerovat vlastní self-signed certifikát a použít jej k podepisování jiných certifikátů. Protože však váš náhodný certifikát není nikde předinstalován jako certifikační autorita do žádného prohlížeče, žádný z nich vám nebude důvěřovat ani při podepisování vlastních, ani jiných certifikátů. Tím vlastně říkáte: „Ehm, jo, já jsem úplně Microsoft, tady je oficiální certifikát identity vydaný a podepsaný mnou.“ A všechny správně fungující prohlížeče v reakci na vaše pochybné pověření vyhodí velmi děsivou chybovou zprávu.

To klade obrovskou zátěž na všechny vydavatele prohlížečů a operačních systémů, aby důvěřovali pouze bezchybným kořenovým certifikačním autoritám, protože to jsou organizace, kterým jejich uživatelé nakonec důvěřují, že prověřují webové stránky a zajišťují bezpečnost certifikátů. To není snadný úkol.

3.4 Čemu věříte?

Zajímavé je, že váš klient se technicky vzato nesnaží ověřit, zda má či nemá věřit straně, která mu certifikát poslala, ale zda má věřit veřejnému klíči obsaženému v certifikátu. Certifikáty SSL jsou zcela otevřené a veřejné, takže jakýkoli útočník může získat certifikát společnosti Microsoft, zachytit požadavek klienta na Microsoft.com a předložit mu legitimní certifikát. Klient by jej přijal a s radostí by zahájil handshake. Když však klient zašifruje klíč, který bude použit pro skutečné šifrování dat, učiní tak pomocí skutečného veřejného klíče společnosti Microsoft z tohoto skutečného certifikátu. Protože útočník nemá k dispozici soukromý klíč společnosti Microsoft, aby jej mohl dešifrovat, je nyní v koncích. I když bude handshake dokončen, stále nebude schopen dešifrovat klíč, a nebude tedy schopen dešifrovat žádná data, která mu klient pošle. Pořádek je zachován, dokud útočník neovládá soukromý klíč důvěryhodného certifikátu. Pokud je klient nějakým způsobem podveden, aby důvěřoval certifikátu a veřejnému klíči, jehož soukromý klíč ovládá útočník, začínají problémy.

4.1 Může kavárna sledovat můj provoz HTTPS ve své síti?

Ne. Kouzlo kryptografie s veřejným klíčem znamená, že útočník může sledovat každý jednotlivý bajt dat vyměňovaných mezi vaším klientem a serverem, a přesto netuší, co si navzájem říkáte, kromě toho, kolik dat si zhruba vyměňujete. Váš běžný provoz HTTP je však v nezabezpečené síti wi-fi stále velmi zranitelný a chatrné webové stránky se mohou stát obětí libovolného počtu obcházení, které vás nějakým způsobem obelstí a pošlou provoz HTTPS buď přes obyčejný HTTP, nebo prostě úplně jinam. Například i když přihlašovací formulář odesílá kombinaci uživatelského jména a hesla přes protokol HTTPS, pokud je samotný formulář načten nezabezpečeně přes protokol HTTP, může útočník zachytit HTML formuláře na cestě do vašeho počítače a upravit jej tak, aby odeslal přihlašovací údaje do svého vlastního koncového bodu.

4.2 Může moje společnost monitorovat můj provoz HTTPS přes svou síť?

Pokud používáte také počítač kontrolovaný vaší společností, pak ano. Nezapomeňte, že v kořeni každého řetězce důvěry leží implicitně důvěryhodná certifikační autorita a že seznam těchto autorit je uložen ve vašem prohlížeči. Vaše společnost by mohla využít svůj přístup k vašemu počítači a přidat do tohoto seznamu certifikačních autorit svůj vlastní certifikát podepsaný vlastním podpisem. Mohla by pak zachytit všechny vaše požadavky na protokol HTTPS a předkládat certifikáty, které tvrdí, že zastupují příslušné webové stránky, jsou podepsané jejich falešnou certifikační autoritou, a proto jim váš prohlížeč bezvýhradně důvěřuje. Protože byste všechny své požadavky HTTPS šifrovali pomocí veřejného klíče jejich podvrženého certifikátu, mohli by pomocí odpovídajícího soukromého klíče váš požadavek dešifrovat a zkontrolovat (dokonce upravit) a poté jej odeslat na určené místo. Pravděpodobně to nedělají. Ale mohli by.

Shodou okolností je to také způsob, jak pomocí proxy serveru zkontrolovat a upravit jinak nedostupné požadavky HTTPS odeslané aplikací pro iPhone.

4.3 Jak to tedy bylo s Lavabitem a FBI?

Lavabit byl superbezpečný poskytovatel e-mailu Edwarda Snowdena během šílenství s úniky informací z NSA v roce 2013. Jak jsme viděli, žádný standardní hackerský útok nemohl FBI umožnit, aby viděla jakákoli data na cestě mezi společností Lavabit a jejími zákazníky. Bez soukromého klíče k SSL certifikátu Lavabit byla agentura v háji. Ochotný americký soudce však zakladateli Lavabitu Ladaru Levisonovi sdělil, že tento klíč musí předat, čímž fakticky dal FBI volnou ruku ke slídění v provozu podle svého uvážení. Levison se statečně pokusil zdržovat předáním klíče o 2560 znacích na 11 tištěných stranách psaných čtyřbodovým písmem, ale dostal příkaz, podle kterého musel klíč předat v použitelném formátu, jinak mu hrozí pokuta 5000 dolarů denně, dokud tak neučiní.

Když vyhověl, GoDaddy, certifikační autorita Lavabitu, certifikát zrušila, protože ho (správně) považovala za kompromitovaný. Tím byl certifikát Lavabit přidán na seznam odvolaných certifikátů (Certificate Revocation List, CRL), tedy seznam zdiskreditovaných certifikátů, kterým by klienti již neměli důvěřovat, pokud jde o zajištění bezpečného připojení. Kompromitované, vlastnoručně podepsané nebo jinak nedůvěryhodné certifikáty způsobují, že prohlížeče zobrazují velkou červenou chybovou zprávu a odrazují uživatele od další činnosti nebo ji přímo zakazují. Prohlížeče bohužel budou poškozenému certifikátu důvěřovat, dokud nevytáhnou nejnovější aktualizace seznamu CRL, což je proces, který je v praxi zřejmě nedokonalý.

Závěr

HTTPS není neprolomitelný a protokol SSL se musí neustále vyvíjet, protože jsou objevovány a potlačovány nové útoky proti němu. Stále se však jedná o působivě robustní způsob přenosu tajných dat, aniž by vás zajímalo, kdo vaše zprávy uvidí. Existuje samozřejmě mnoho implementačních detailů, které zde nejsou zmíněny, například přesný formát a pořadí zpráv handshake, zkrácené handshake pro zachycení nedávných relací bez nutnosti znovu vyjednávat klíče a sady šifer a mnoho různých možností šifrování dostupných v každé fázi. Klíčové je si uvědomit, že protokol HTTPS sice zajišťuje bezpečnost dat na cestě k cíli, ale v žádném případě vás (jako uživatele nebo vývojáře) nechrání před XSS, únikem dat z databáze nebo jinými věcmi, které se stávají v noci. Buďte rádi, že vám kryje záda, ale buďte ostražití. Řečeno nesmrtelnými slovy Willa Smithe: „Choďte ve stínu, pohybujte se v tichosti, chraňte se před mimozemským násilím.“

Pokud se vám tento článek líbil, pravděpodobně se vám bude líbit i můj příspěvek vysvětlující podrobnosti zranitelnosti FREAK v SSL z roku 2015.