Vlákno názorů k článku Cloudbleed: únik dat sdíleného proxy serveru od Filip Jirsák - Připomíná to, že mít SSL ve stejném procesu,...

Připomíná to, že mít SSL ve stejném procesu, jako všechno ostatní, není dobrý nápad. V tomhle případě sice privátní klíče k SSL neunikly, protože se náhodou SSL terminuje na jiných instancích, ale bylo to spíš štěstí než záměr.

Neřeší některý z mnoha forků OpenSSL právě tohle, tj. zachování API OpenSSL ale oddělení implementace do samostatného procesu? Vlastně takové „softwarové HSM“ – klíče by se držely v samostatném procesu, který by pro hlavní proces prováděl šifrování a dešifrování. Protože držet privátní klíče v paměti hlavního procesu webového serveru evidentně není bezpečné.

Existuje projekt SoftHSM, který implementuje HSM s rozhraním PKCS #11. Ale rozhraní je ve formě sdílené knihovny, takže paměť nejspíš bude přístupna z propojeného procesu.

Otázka je, jestli vyzrazení privátního klíče k certifikátu může nějak zásadně zhoršit současnou situaci. Já si myslím, že ne. Drtivá většina certifikátů je vydaných automaticky přímo prostřednictvím Cloudflare a tam by byla změna klíče bez problému. Slušné komerční CA také obvykle nabízí změnu klíče v ceně. V porovnání s tím, že při útoku unikly přihlašovací údaje a autentizační tokeny ke známým službám plným osobních údajů by tak byl únik privátních klíčů už jen více méně nepodstatný detail.

Myslel jsem to obecně, Cloudflare je dost specifický případ. Heartbleed podle mne byl docela problém. A kdyby Cloudflare unikly uživatelské privátní klíče, taky by to byl průšvih.

OpenSSL jsem vybral jako příklad, který se dá relativně snadno vyřešit jen na serveru. Ty přihlašovací údaje a tokeny jsou samozřejmě také problém, ale tam jako hlavní problém vidím to, že je server vůbec zná. Kdyby se k autentizaci používal HTTP Digest (nebo něco modernějšího), může být opět zahashované heslo dostupné jen v paměti jiného procesu, který nebude dělat nic jiného, než ověřování.

OAuth tokeny k jiným službám webová aplikace musí znát (pokud se nepoužívají mikroslužby). To ale neznamená, že se nevyplatí chránit vůbec nic. Vyměnit OAuth tokeny je mnohem jednodušší, než měnit hesla všem uživatelům. A vyzrazený OAuth token obvykle není takový průšvih, jako vyzrazený privátní klíč.

Na Linuxu platí, že při alokaci paměti od jádra získáte vynulovanou paměť, a mělo by to platit pro každý rozumný OS. Pokud by jádro mohlo procesu přidělit paměť s daty z jiného programu, byla by to bezpečnostní díra jak vrata. Kterýkoli proces může být kdykoli násilně ukončen a nemá čas po sobě čistit paměť.

Nejde o to, že Cloudflare ta data zná – to je samozřejmé a při použití takové služby jí musím důvěřovat. Jde o to, že čtení z paměti, která mi nepatří, se prostě ve webovém serveru může stát – a je docela hloupé, když takhle uniknou třeba privátní klíče, které v paměti toho procesu vůbec být nemusí. Je pikantní, že v případě Heartbleed za ten únik paměti mohla zrovna knihovna OpenSSL. A to, že v případě Cloudflare nedošlo k úniku privátních klíčů klientů, je podle mne vedlejší efekt, terminaci SSL na speciálních instancích podle mne neměli primárně kvůli bezpečnosti, ale kvůli optimálnímu využití hardware.

Žádná jiná knihovna nezabrání kompromitaci privátního klíče, pokud bude klíč držen v paměti hlavního procesu a jakýkoli kód v tom hlavním procesu bude omylem číst a odesílat cizí paměť. Může to být chyba v parseru HTML,jako tentokrát, nebo v čemkoli jiném – v parseru HTML, v generátoru obrázků, v kompresní nebo dekompresní knihovně, ve frameworku, ve vlastní webové aplikaci…

Kdybyste si přečetl tu analýzu od Cloudflare, která je ve zprávičce i odkazovaná, nemusel jste tapetovat diskusi nesmysly. Cloudflare totiž neterminuje SSL na speciálním hardwaru, ale v Nginxu: „Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.“ Akorát je to (shodou okolností) jiná instance Nginxu, než ta, která provádí tu transformaci HTML. Přičemž důvod je předpokládám výkonnostní – pro terminaci SSL je vhodné mít akcelerované kryptografické funkce, což je naopak zbytečné pro přepis HTML.

Víte, Cloudflare není pár domácích serverů, že by měli 30 serverů a měli by pocit, bůhvíco nemají. To je cloud, který se řeší velkým množstvím spotřebních komponent. Specializovaný hardwarový akcelerátor SSL není pro Cloudflare vhodný, protože ten má určité parametry (podporované algoritmy a protokoly), a tím jsou jeho možnosti dané. Maximálně můžete doufat, že dodavatel vydá nový firmware s podporou nového protokolu. Což je pro Cloudflare nevhodné, když je poskytování HTTPS služeb součástí jejich core byznysu, takže potřebují být schopní naimplementovat to, co si sami rozhodnout. Proto je pro ně lepší používat běžný hardware s obecnou akcelerací použitelnou při implementaci kryptografických algoritmů, a SSL řešit softwarově (v Nginxu).