HTTPS se šíří světem, Let's Encrypt vydal 20 milionů certifikátů a Mozilla tvrdí, že přibližně každá druhá stránka je načtena pomocí HTTPS. Přesto je možné pro zabezpečení udělat ještě více – můžete bezpečnost vynutit pomocí rozšiřujících hlaviček HSTS a HPKP. Ty mají na rozdíl od záznamů TLSA (DANE) širokou podporu v současných prohlížečích.
Proč?
I když máte web dobře nakonfigurovaný, certifikáty platné a šifry silné, stále existují útoky, které dokáží uživatele ohrozit. Tím prvním je takzvaný HTTPS stripping. Vychází z toho, že většina uživatelů zadává do prohlížeče zkrácenou verzi adresy („root.cz“) a server je pak přes nešifrované spojení přesměruje na šifrovanou variantu.
$ curl -I www.root.cz HTTP/1.1 301 Moved Permanently … Location: https://www.root.cz/ …
Pokud útočník stojí mezi oběma komunikujícími stranami a dokáže ovlivňovat komunikaci, může už v tuto chvíli převzít iniciativu a přesměrování neposlat. Poté může zůstat na HTTP a servírovat uživateli vlastní obsah. V praxi si většina uživatelů nevšimne, že zrovna chybí zámeček.
Některé weby tomu nahrávají tím, že například běžný obsah zobrazují po HTTP a teprve při přechodu na přihlášení vede odkaz na HTTPS. Uživatel si musí aktivně zkontrolovat, že je skutečně najednou na šifrované variantě a může bezpečně zadávat přihlašovací údaje. Pokud to neudělá, může útočník libovolně manipulovat informačním webem a odkaz na přihlašování odvede na svou phishingovou stránku. Překvapivé je, že se tak chová i bankovní web.
Druhým potenciálním (ale reálným) problémem jsou certifikační autority, které mohou v případě chyby vydat jiný certifikát pro tutéž doménu. Pokud se útočníkovi podaří kteroukoliv z autorit zmanipulovat, může si nechat vystavit alternativní certifikát s vlastním veřejným klíčem a pak se může vydávat za původní zdroj. Připomeňme, že se takový útok podařil například na Comodo, Diginotar nebo WoSign. Často je terčem snahy o výměnu certifikátu doména Google.com.
Kudy z toho ven?
Běžné TLS či PKI mechanismy nedokáží těmto útokům zabránit. HTTP komunikaci není možné nijak ochránit. Zároveň v PKI neexistuje pevná vazba doména-klíče. Tu má dodat právě systém certifikačních autorit a žádná vyšší instance tu neexistuje.
Aby měl tento gordický uzel řešení, byly vymyšleny dvě rozšiřující HTTP hlavičky: HSTS a HPKP. Ty informují uživatele (či spíše jeho prohlížeč), že na konkrétním webu platí přísnější režim. Prohlížeč si tuto informaci zapamatuje a napříště se k webu bude chovat jinak. Tomuto principu se říká TOFU – Trust On First Use.
Buďte opatrní
Je slušností upozornit na případné problémy na začátku. Tedy ještě než si při čtení článku něco rozbijete a pak zjistíte, že varování následuje. Rozhodně doporučuji se zmíněnými hlavičkami zabývat a pokud to s bezpečností HTTPS myslíte vážně, měli byste je nasadit. Dělejte to ale s rozmyslem.
Pokud to uděláte špatně, existuje šance, že si znepřístupníte web. Nebudete první ani poslední, ale může vám být velmi horko. Zejména v případě HPKP nemusí být cesty zpět a váš web může zůstat pro uživatele dlouho nepřístupný.
Obecně u podobných věcí souvisejících s bezpečností a šifrování platí, že byste je ve firmě měli nějakým způsobem dokumentovat a zavést do vnitřních pochodů. Kolega musí vědět, že když mění certifikát, nesmí zapomenout na tyhle podstatné věci. Platí tu víc než kde jinde: dvakrát měř, jednou řež.
HSTS: tady se šifruje
Hlavička HSTS je zkratkou pro HTTP Strict Transport Security a přináší přísnou bezpečnost přenosového protokolu. Zavádí ji RFC 6797. Uživateli v ní vlastně sdělujeme: „na tomto webu se vždy šifruje a používá se vždy důvěryhodný certifikát“. Pozor na to, že se hlavička vztahuje na všechny porty, takže pokud si například spustíte testovací web server na 8080, musí také podporovat HTTPS a mít validní certifikát.
V praxi tak prohlížeč po naučení této hlavičky zareaguje tím, že automaticky přepíše protokol v adrese na HTTPS. Zcela se tím obchází nutnost explicitního přesměrování, protože uživatel se už nikdy nebude k webu připojovat pomocí nešifrovaného HTTP. Hlavička je pro prohlížeč platná jen ve chvíli, kdy přijde po HTTPS.
V praxi hlavička vypadá takto:
$ curl -I https://cs.wikipedia.org/ … Strict-Transport-Security: max-age=31536000; includeSubDomains; preload …
Hlavička má v tomto případě tři parametry: první (a jediný povinný) uvádí počet sekund platnosti hlavičky (v příkladu je to 365 dnů), druhá rozšiřuje platnost na subdomény (*.wikipedia.org) a třetí povoluje preload (zmíníme dále).
Časový údaj v keši prohlížeče je při každé návštěvě znovu přepsán. Platnost se tak opakovaně prodlužuje na nastavenou hodnotu. Past se skrývá ve druhém parametru, při jehož nasazení si musíte být bezpodmínečně jisti, že všechny subdomény jsou schopny správně fungovat s HTTPS a mají důvěryhodný certifikát. V opačném případě je uživateli znepřístupníte.
Pokud totiž uživatel o HSTS už ví a web má rozbité HTTPS (třeba neplatný certifikát nebo chybějící mezilehlý), uživatel obdrží klasickou chybu o nedůvěryhodném spojení, ale chybí volba pro pokračování. Jednou správce deklaroval bezpečné HTTPS a tudy vlak nejede.
Preload aneb seznam v prohlížeči
HSTS je možné zařídit ještě účinněji pomocí takzvaného preloadu. K uživateli se informace o vynuceném šifrování dostává už předinstalovaná v prohlížeči a on se nemusí spoléhat na první návštěvu webu.
Aby bylo možné web do tohoto seznamu dostat, musí splňovat několik pravidel:
- používat důvěryhodný certifikát
- přesměrovávat správně z HTTP na HTTPS
- provozovat HTTPS na subdoménách (minimálně musí existovat www)
- mít HSTS se všemi třemi výše uvedenými parametry
- dobu platnosti (max-age) mít alespoň 18 týdnů (10886400 sekund)
Teprve v tu chvíli je možné vyplnit žádost a nechat se do seznamů zařadit. Výsledek je možné vidět ve zdrojových kódech projektu Chromium, odkud je přebírá Google, ale také například Mozilla. K uživateli se pak nová verze seznamu dostane s příští verzí prohlížeče.
HPKP: používáme tyto klíče a žádné jiné
Před výměnou certifikační autority a klíčů serveru chrání hlavička HPKP, což je zkratka HTTP Public Key Pinning – připíchnutí veřejného klíče. Zavedeno bylo v RFC 7469 V mnoha ohledech je podobná už popsané hlavičce HSTS, ale je konkrétnější – vyjmenovává konkrétní klíče (pomocí jejich otisků), které mohou být na daném webu používány. Jiné klíče pak prohlížeč nepřijme.
Přesně v tomto bodě se vyplatí velká opatrnost, protože když o klíče přijdeme, nedokážeme se už s uživatelem bezpečně spojit a odřízneme jej od sebe. Naštěstí na to tvůrci mysleli a aby byla hlavička platná, musí obsahovat také záložní klíč. V praxi tedy musí být serverem odeslány minimálně dva otisky – jeden se musí nacházet v právě používaných klíčích a druhý naopak nesmí.
Například GitHub ale posílá celou řadu klíčů, počet není nijak omezen a na pořadí nezáleží:
$ curl -I https://github.com
…
Public-Key-Pins: max-age=5184000;
pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";
pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho=";
pin-sha256="k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K+59sNQws=";
pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q=";
pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4=";
pin-sha256="iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0=";
pin-sha256="LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A=";
includeSubDomains
…
Vidíte, že dva parametry jsou vám už známé – délka platnosti a rozšíření na subdomény. Zároveň jsou tu vidět otisky všech klíčů, které jsou na GitHubu povoleny. Některé z nich jsou pravděpodobně záložní.
U klíčů není nijak stanoveno, kde se v PKI řetězci musí nacházet. Je takto možné zapinovat kořen autority, libovolný klíč v mezilehlém certifikátu nebo až v tom koncovém. Většině nasazení bude pravděpodobně nejvíce vyhovovat koncový certifikát, ale třeba Google využívá vlastní mezilehlou autoritu, takže by mohl ji stanovit jako pevný bod.
Pokud se rozhodnete pinovat některý z nadřazených certifikátů, vybíráte jako důvěryhodnou jen konkrétní autoritu. Tím sice vylučujete všechny ostatní, ale zároveň může být vaše autorita zneužita k vystavení alternativních certifikátů s jiným klíčem. Co je ještě horší, autorita se může rozhodnout vyměnit mezilehlý certifikát a s ním i svůj klíč. V takové situaci se můžete opět zamotat – naštěstí můžete záložní klíč použít v koncovém certifikátu, což situaci řeší.
Pokud chcete záznamy generovat, můžete použít online generátor, který načte všechny certifikáty a vytvoří z nich správné otisky. Konkrétně jde o položku Subject Public Key Info (SPKI) z X.509 certifikátu ve formátu ASN.1 v kódování DER. Z uživatelského hlediska ale stačí vložit URL a výsledkem jsou rovnou HPKP záznamy.
HPKP preload jen pro vyvolené
Také HPKP má svou variantu preloadu, jak se můžete přesvědčit v nastavení prohlížeče Chrome. Stačí navštívit adresu chrome://net-internals/#hsts a zadat si například Google.com, Facebook.com, Twitter.com nebo GitHub.com. Kromě informací o HSTS se tu dozvíte také informace o povolených klíčích v HPKP.
Bohužel na tento seznam není možné se jednoduše zapsat, jde o seznam pro vyvolené. Jedním z důvodů může být také fakt, že otisky klíčů jsou poměrně velké a pokud by se do preloadu zapsalo velké množství domén, databáze by velmi rychle rostla.
HSTS a HPKP nejsou pro každého a neřeší vše
Obě rozšířující hlavičky jsou velmi užitečné a dokáží výrazně zvýšit zabezpečení webu. Podle mého názoru dává mnohem větší smysl například kombinace autority Let's Encrypt právě s HSTS a HPKP než prosté nasazení drahé „velké“ autority.
Přesto není nasazení pro každého, správce si musí být skutečně jistý tím, že ví, co dělá. V opačném případě může dveře zabouchnout nejen před útočníkem, ale také před uživateli i sebou samým.
