Jak funguje HTTPS, jednoduše

HTTPS je obyčejné HTTP - stejné požadavky, stejné stránky - poslané šifrovaným tunelem zvaným TLS. Dřív než se přenese jediný bajt stránky, se prohlížeč se serverem dohodnou na tajném klíči, který nikdo, kdo sleduje síť, nedokáže zjistit, a server pomocí certifikátu prokáže, že je opravdu tím webem, jehož jméno jsi napsal. Potom ten, kdo je mezi tebou a serverem, vidí jen to, že ses připojil k určité adrese a zhruba kolik dat šlo oběma směry. Nevidí stránky, formuláře, hesla ani cookies a nemůže na nich nic změnit, aniž by se spojení přerušilo.

To je celá myšlenka. Zbytek článku popisuje, jak funguje každá část, co zámeček slibuje a co ne a proč HTTPS potřebuje i web, který nemá co skrývat.

HTTP vs HTTPS: co se vlastně mění#

Obyčejné HTTP je text posílaný otevřeně. Požadavek na přihlašovací stránku vypadá na drátě přesně tak, jak ho napsal prohlížeč:

POST /login HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencodedemail=anna%40example.com&password=herring-barrel-42

Každé zařízení, které ten paket přenáší - router v kavárně, síťová krabička v hotelu, poskytovatel připojení, jakýkoli stroj mezi nimi - ho může přečíst, uložit nebo přepsat. Přepisování není teoretické: poskytovatelé a veřejné hotspoty do nešifrovaných HTTP stránek už roky vkládají reklamy, sledovací skripty a bannery typu „blížíte se k limitu dat“.

HTTPS mění přenos a nic nad ním:

Aplikace se nemění. Stejný kód serveru, stejné HTML, stejné cookies - TLS obalí spojení a HTTP běží uvnitř, aniž by o tom vědělo. Proto se také „SSL“ a „TLS“ používají zaměnitelně: SSL byl původní protokol z 90. let, TLS je jeho nástupce a všechny verze SSL byly oficiálně vyřazeny jako nezabezpečené. Čemu se dnes říká „SSL certifikát“, se používá výhradně s TLS a současné verze jsou TLS 1.2 a TLS 1.3. TLS 1.0 a 1.1 byly zastaralé v roce 2021 a moderní prohlížeče je odmítají.

Dva druhy šifrování, které používá#

HTTPS kombinuje dvě rodiny kryptografie, protože každá je dobrá v tom, v čem je ta druhá slabá.

Symetrické šifrování používá jeden klíč k zamykání i odemykání. Je dost rychlé na to, aby v telefonu šifrovalo video v reálném čase. Jeho slabina je zjevná: obě strany potřebují stejný klíč a ten nemůžeš jen tak poslat po síti, kterou se snažíš chránit. V praxi se používají šifry AES v režimu GCM a ChaCha20-Poly1305; obě navíc odhalí jakoukoli změnu dat, takže se zachytí nejen odposlech, ale i manipulace.

Asymetrická kryptografie (s veřejným klíčem) používá dvojici klíčů. Co jeden klíč udělá, může ověřit nebo vrátit zpět jen ten druhý. Jedna polovina je veřejná a dostane ji kdokoli, druhá je soukromá a server ji nikdy neopustí. Je to pomalé, ale řeší to dva těžké problémy: dva cizí lidé se mohou po otevřené lince dohodnout na sdíleném tajemství a jeden z nich může dokázat, kdo je, aniž by prozradil cokoli, co by šlo znovu použít.

HTTPS tedy používá pomalý, důmyslný druh jednou na začátku, aby se dohodlo na klíči a ověřila identita, a rychlý druh na všechno potom. Dohodou je výměna klíčů - v praxi varianta Diffieho-Hellmana nad eliptickými křivkami, například X25519. Každá strana zvolí náhodné tajemství, pošle hodnotu z něj odvozenou a obě strany spojí to, co dostaly, s vlastním tajemstvím a dojdou ke stejnému číslu. Pozorovatel, který viděl obě hodnoty při přenosu, ho přesto spočítat nedokáže.

Stojí za to znát jeden detail: moderní TLS tato tajemství výměny po každém spojení zahodí. Říká se tomu forward secrecy (dopředné utajení) a znamená to, že i když se příští rok ukradne soukromý klíč serveru, provoz zaznamenaný dnes se stále nedá dešifrovat. TLS 1.3 ho vyžaduje vždy; starší nastavení, která šifrovala klíč relace přímo klíčem z certifikátu serveru, ho neměla.

Certifikáty a certifikační autority#

Samotné šifrování nestačí. Pokud útočník sedí mezi tebou a serverem, může s tebou vést dokonale šifrované spojení a další se skutečným serverem a uprostřed všechno číst. Výměna klíčů by se se špatnou stranou povedla. Co tomu brání, je certifikát.

Certifikát je malý soubor, který váže veřejný klíč k jednomu či více jménům. Jeho důležitá pole:

• Subject alternative names - jména hostitelů, pro která platí, například example.com a www.example.com, nebo zástupný zápis jako *.example.com, který pokrývá jednu úroveň subdomén.
• Veřejný klíč - veřejná polovina páru klíčů, jehož soukromá polovina leží na serveru.
• Platnost - datum „není platný před“ a „není platný po“. Mimo toto okno se certifikát odmítne.
• Vydavatel a podpis - která autorita za tuto vazbu ručí, a její digitální podpis přes všechno výše uvedené.

Podstatná je ta autorita. Certifikační autorita (CA) je organizace, jejíž vlastní veřejné klíče jsou součástí tvého operačního systému nebo prohlížeče, v seznamu zvaném root store. Mozilla, Apple, Microsoft a Google si každá vedou svůj a autority v něm auditují. Když CA podepíše certifikát, prohlašuje tím, že si ověřila, že žadatel ovládá dané jméno. U bezplatných certifikátů, které používá většina webů, je tato kontrola automatická: CA požádá žadatele, aby na doméně zveřejnil token, a stáhne si ho - přesně jak tato výzva probíhá, popisuje článek HTTPS a Let's Encrypt vysvětleno.

Kořenové klíče se uchovávají offline a používají se zřídka, proto CA podepíše tvůj certifikát zprostředkujícím klíčem a ten je podepsaný kořenem. Server posílá svůj certifikát plus zprostředkující; kořen už prohlížeč má. To je celý řetězec:

Prohlížeč kontroluje jeden podpis za druhým směrem nahoru, dokud nenarazí na kořen, kterému už důvěřuje. Pokud některý článek chybí, vypršel nebo je podepsaný něčím neznámým, spojení se odmítne s varováním. Server, který pošle jen svůj certifikát a zapomene na zprostředkující, je klasická chyba v konfiguraci a je protivná, protože v některých prohlížečích funguje - v těch, které si zprostředkující certifikát náhodou uložily z jiného webu - a v jiných selže.

Každý veřejný certifikát se také zapisuje do logů Certificate Transparency, veřejných záznamů, do nichž se jen přidává a v nichž může vyhledávat kdokoli. Prohlížeče vyžadují důkaz, že byl certifikát zalogován. Výsledkem je, že CA nemůže potichu vydat certifikát pro tvou doménu někomu jinému, aniž by po sobě zanechala stopu, kterou najdeš.

TLS handshake krok za krokem#

Když otevřeš https://example.com, tohle se stane dřív, než dorazí první bajt HTML. Popis odpovídá TLS 1.3, které si dojedná téměř každý současný prohlížeč a server; TLS 1.2 se řídí stejnou logikou s jedním obousměrným oběhem navíc.

1. Spojení TCP. Prohlížeč přeloží jméno přes DNS a otevře spojení na port 443 na dané adrese. (Vyhledávání popisuje článek DNS záznamy vysvětleno.)
2. ClientHello. Prohlížeč pošle verze TLS a šifry, které podporuje, náhodnou hodnotu, svou polovinu výměny klíčů („key share“) a dvě důležitá rozšíření: SNI, tedy jméno hostitele, které chce, aby server hostující mnoho webů věděl, který certifikát předložit; a ALPN, protokoly, kterými umí mluvit, například h2 pro HTTP/2.
3. ServerHello. Server vybere verzi a šifru a pošle svůj vlastní key share. V tomto okamžiku mohou obě strany spočítat stejné tajemství a od teď je všechno šifrované.
4. Certificate. Server pošle svůj certifikát a řetězec zprostředkujících.
5. CertificateVerify. Server svým soukromým klíčem podepíše hash celé dosavadní konverzace. To je důkaz identity: takový podpis mohl vytvořit jen držitel soukromého klíče odpovídajícího certifikátu, a protože zahrnuje náhodné hodnoty této konverzace, nelze ho přehrát ze staré.
6. Finished. Server pošle krátkou kontrolní hodnotu přes celý handshake, která dokazuje, že se při přenosu nic nezměnilo.
7. Kontroly klienta. Prohlížeč ověří řetězec až ke kořeni, kterému důvěřuje, data platnosti, že jméno v adresním řádku je na seznamu jmen v certifikátu, a podpis z kroku 5. Jakékoli selhání tady spojení zastaví a zobrazí se stránka s varováním.
8. Client Finished, pak HTTP. Prohlížeč pošle vlastní zprávu Finished a hned za ní obyčejný požadavek GET - už uvnitř šifrovaných záznamů.

Celé to stojí jeden síťový oběh, než může odejít požadavek - zhruba tolik, co jeden ping na server. Vracející se návštěvník může navázat předchozí relaci a přeskočit krok s certifikátem a TLS 1.3 při obnově dokonce dovoluje poslat data už v úplně prvním paketu („0-RTT“), za cenu toho, že tato raná data jdou přehrát, a proto je servery přijímají jen u požadavků, které je bezpečné opakovat.

Skutečný handshake si můžeš prohlédnout z terminálu:

# Summary: protocol, cipher, certificate subject and issuer$ openssl s_client -connect example.com:443 -servername example.com -brief < /dev/null# The same from curl, with every TLS step printed$ curl -v https://example.com -o /dev/null

Přepínač -servername nastavuje SNI. Bez něj může server hostující více jmen vrátit výchozí certifikát nějakého jiného webu a výsledek vypadá jako rozbitý certifikát, i když ve skutečnosti chybí jen přepínač.

HTTP/3 mění přenos pod sebou - běží přes QUIC na UDP portu 443 místo TCP - ale handshake TLS 1.3 je vestavěný do QUIC a výše uvedené kroky se pořád odehrávají.

Co znamená zámeček a co ne#

Zámeček, nebo v současném Chrome neutrální ikona nastavení na stejném místě, znamená přesně tři věci: spojení je šifrované, při přenosu se nezměnilo a server prokázal, že drží platný certifikát pro jméno v adresním řádku. To je výpověď o potrubí, ne o lidech na druhém konci.

Neznamená to:

• Že je web poctivý. Phishingová stránka na paypa1-secure-login.com dostane platný certifikát během vteřin, protože certifikát dokazuje jen kontrolu nad přesně tímto jménem. Čti jméno, ne ikonu.
• Že firma je, kým tvrdí. Běžné bezplatné certifikáty jsou ověřené jen pro doménu. Dražší certifikáty s ověřenou organizací a s rozšířeným ověřením zahrnují kontrolu firemních záznamů, ale prohlížeče už název firmy v adresním řádku nezobrazují, takže je návštěvník nerozliší.
• Že je web zabezpečený. HTTPS chrání data při přenosu. Nic nedělá proti zastaralému pluginu, slabému heslu správce nebo databázi otevřené do internetu. Lepším průvodcem touto stránkou je zabezpečení WordPressu.
• Že nikdo nevidí, že jsi web navštívil. Pozorovatel v síti pořád vidí IP adresu serveru a obvykle i jméno hostitele: SNI v ClientHello se posílá nešifrovaně, pokud prohlížeč i server nepodporují Encrypted Client Hello, které se teprve zavádí, a dotaz na DNS je čistý text, pokud zařízení nepoužívá šifrované DNS. Nevidí cestu, query string, hlavičky, cookies ani obsah. https://example.com/account/orders?id=4411 prozradí example.com; zbytek zůstane v tunelu.
• Že to nemůže číst tvůj zaměstnavatel nebo škola. Firemní sítě a některé antiviry instalují na spravovaná zařízení vlastní kořenový certifikát a provoz uprostřed záměrně dešifrují. Na zařízení, které nemáš pod kontrolou, počítej s tím, že je to možné. Průnik s VPN popisuje článek co VPN chrání a co ne.

HSTS: uzavření mezery u prvního požadavku#

I web, který přesměrovává každý požadavek HTTP na HTTPS, má slabý okamžik: úplně první požadavek. Když napíšeš example.com, prohlížeč zkusí nejdřív http:// a tento nešifrovaný požadavek se dá zachytit dřív, než přijde přesměrování. Útočník ve stejné wifi na něj může odpovědět sám a nechat tě na HTTP libovolně dlouho - tomu se říká downgrade útok.

HSTS (HTTP Strict Transport Security) tuto mezeru uzavírá. Server pošle jednou přes HTTPS hlavičku:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Od té chvíle po dobu max-age sekund - tady rok - prohlížeč přepíše každý odkaz http:// na toto jméno na https://, než cokoli odešle, a odebere možnost proklikat se varováním o certifikátu. První návštěva je stále nechráněná, a k tomu slouží preload list: jména do něj přihlášená jsou natvrdo zapsaná v prohlížečích jako pouze HTTPS ještě před první návštěvou. Na tom seznamu jsou i celé domény nejvyšší úrovně, například .dev a .app, takže každý web pod nimi musí od prvního dne servírovat HTTPS.

HSTS je jediná funkce HTTPS, která tě může zamknout venku z vlastního webu, pokud nějaká subdoména pořád potřebuje obyčejné HTTP, a preloading se vrací zpět pomalu. Začni s krátkým max-age, ověř, že všechno funguje, a pak ho zvyš. Konfigurace spolu s přesměrováním a úklidem smíšeného obsahu, které by měly přijít první, je v článku HTTPS a Let's Encrypt vysvětleno.

Proč HTTPS potřebuje každý web#

„Můj web nemá přihlášení ani platby“ je obvyklý argument proti tomu, se tím zabývat. Dnes už neplatí, a to z důvodů, které s utajením nemají nic společného.

• Prohlížeče označují obyčejné HTTP jako nezabezpečené, v adresním řádku, na každé stránce. Formuláře na stránkách s HTTP dostanou další varování, když někdo začne psát, a prohlížeče se stále častěji snaží nejdřív o HTTPS a před návratem k obyčejnému HTTP varují.
• Manipulace se týká i nudných stránek. Vložený skript na statickém blogu s recepty běží v prohlížeči návštěvníka se stejnou mocí jako ten tvůj: může přesměrovat, těžit kryptoměny nebo zobrazit falešné přihlášení.
• Moderní funkce ho vyžadují. Geolokace, přístup ke kameře a mikrofonu, service workery, push notifikace, clipboard API a HTTP/2 v prohlížečích potřebují zabezpečený kontext. Prohlížeče používají HTTP/2 a HTTP/3 jen přes TLS, takže web jen s HTTP uvízl i na starším a pomalejším protokolu.
• Vyhledávače ho preferují. Google používá HTTPS jako signál pro řazení od roku 2014. Je to malý signál, ale nic nestojí.
• Údaje o referreru přežijí. Když návštěvník klikne z HTTPS stránky na HTTP, prohlížeč referrer odstraní, takže weby na HTTP přicházejí o část analytiky.
• Certifikát je zdarma a obnovuje se sám. Argument o ceně zmizel, když se bezplatné automatické certifikáty staly normou.

V plánech pro aplikace a weby u RE:NODE se práce zredukuje na jediný záznam DNS: přidej jméno hostitele do slotu proxy, nasměruj záznam A na adresu, kterou ukazuje, a certifikát se vydá, jakmile se jméno přeloží, a obnovuje se automaticky v okně 21 dnů. Proxy ukončuje TLS a posílá obyčejné HTTP tvé aplikaci, se skutečnou adresou návštěvníka v X-Forwarded-For. Toto nastavení a důvody, proč vydání selže, popisuje článek nasměruj doménu na server a přidej SSL.

Chyby certifikátu a co znamenají#

Většina problémů s HTTPS se projeví jako jedna z několika chyb v prohlížeči. Kódy se mezi prohlížeči liší; příčiny jsou stejné.

Vypršel. Buď selhala obnova na straně webu, nebo má návštěvník špatně nastavené hodiny zařízení. Telefon nebo PC s datem o roky zpátky odmítne najednou všechny certifikáty na internetu, což je prozrazující znamení: když nefunguje každý web, zkontroluj hodiny.

Špatné jméno. Certifikát pokrývá example.com, ale návštěvník přišel přes www.example.com, nebo se nová subdoména nasměrovala na server dřív, než pro ni byl vydán certifikát. Certifikát platí jen pro jména, která jsou v něm uvedená.

Neznámý vydavatel. Server neposílá zprostředkující certifikát, nebo je certifikát self-signed (podepsaný sám sebou). Vyzkoušej to ze stroje, který web nikdy nenavštívil, nebo použij výše uvedený příkaz openssl, který ukáže řetězec, jejž server skutečně posílá.

Nezabezpečeno, přestože je certifikát platný. Smíšený obsah: stránka je na HTTPS, ale načítá skript, styl nebo obrázek přes http://. Prohlížeče aktivní obsah rovnou blokují a stránka se vykreslí jen napůl. Konzole prohlížeče uvede přesnou URL.

`ERR_TOO_MANY_REDIRECTS`. Obvykle aplikace za proxy, která ukončuje TLS, vidí na svém portu obyčejné HTTP a pořád přesměrovává na HTTPS. Aplikace musí místo toho věřit hlavičce X-Forwarded-Proto od proxy. Proč, vysvětluje článek co dělá reverzní proxy.

Chování webu zvenčí zjistíš dvěma příkazy, které odpoví na většinu otázek:

# Does HTTP redirect to HTTPS, and to which host?$ curl -sI http://example.com | grep -iE "^(HTTP|location)"# Is HSTS set, and for how long?$ curl -sI https://example.com | grep -i strict-transport-security

FAQ#

Je HTTPS totéž co SSL?

V běžné řeči ano. Technicky je HTTPS HTTP přenášené přes TLS a TLS nahradilo SSL v roce 1999. Všechny verze SSL jsou dnes vyřazené jako nezabezpečené, ale staré jméno se ujalo, a proto se certifikáty pořád prodávají jako „SSL certifikáty“. Používají se s TLS 1.2 a 1.3.

Zpomaluje HTTPS web?

Na moderním hardwaru měřitelně ne. Handshake přidá jeden oběh při novém spojení a méně při obnoveném a samotné šifrování běží ve vyhrazených instrukcích procesoru. V praxi jsou weby na HTTPS často rychlejší, protože prohlížeče používají HTTP/2 a HTTP/3 jen přes TLS.

Vidí můj poskytovatel připojení, které weby navštěvuji přes HTTPS?

Vidí IP adresy, ke kterým se připojuješ, a ve většině případů i jméno hostitele - z tvých dotazů na DNS a z pole SNI v handshaku. Nevidí, které stránky jsi otevřel, co jsi na webu hledal ani nic z toho, co jsi napsal. Šifrované DNS a Encrypted Client Hello to dál zužují tam, kde je podporují oba konce.

Jak dlouho certifikát platí?

Bezplatné certifikáty z Let's Encrypt platí 90 dnů a obnovují se automaticky. Průmyslové maximum pro každý veřejně důvěryhodný certifikát se opakovaně zkracovalo a má se dál zkracovat i v příštích letech, a proto ruční roční obnova všude mizí.

Stačí self-signed certifikát?

Pro šifrování na soukromém testovacím serveru ano. Pro veřejný web ne: žádný prohlížeč mu nevěří, takže každý návštěvník dostane varování přes celou stránku a učit lidi proklikávat varování maří ověření identity, na kterém HTTPS stojí.

Potřebuju HTTPS pro herní server?

Ne pro samotný herní provoz - Minecraft, Valheim a většina her používá vlastní protokoly na vlastních portech, ne HTTP. Potřebuješ ho pro cokoli webového kolem hry: web, prohlížeč mapy, stránku pro dary nebo panel.