Názory k článku Cloudbleed: únik dat sdíleného proxy serveru
-
Filip JirsákStříbrný podporovatelPř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é.
-
Ondřej CaletkaZlatý podporovatelExistuje 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.
-
Filip JirsákStříbrný podporovatel
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í.
-
. . (neregistrovaný)
tak jde o tokeny třeba pro oauth pro různé služby, tam se http digest použít nedá a zranitelný je v momentě úniku shodně.
Paměť jiného procesu mi nic moc nezaručí, stačí, když paměť daný proces uvolní a nevynuluje, poté si jí vezmu a pořád existuje riziko přetečení a poslání špatných dat.
Cloudfare ty data zná, protože kluci si terminují SSL spojení sami a na backend vytvářejí nová, takže pracuji s nešifrovanými daty a pokud udělají podobnou volovinu, je průser na světě.
-
Filip JirsákStříbrný podporovatel
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.
-
Trident (neregistrovaný)
Jirsak. Neres a neprepinej. Proste se pouziva neco jineho nez OpenSSL - jiny stack s OpenSSL kompatibilnim API vetsinou za chechtaky, specielni moduly pro apache ci jine exkrementy. Pouzivaji se ruzne kombinace. Napriklad oblibena je OpenSSL plus HW akceleratory kdy napriklad nase implementace nebyla vuci heartbleed zranitelna.
Mnohem casteji vsak mas na tyto veci specializovany kus HW s vlastni kompletni implementaci, mnohdy i na bazi nejakych specialnich ASICu nebo FPGA. -
Filip JirsákStříbrný podporovatel
Žá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…
-
Trident (neregistrovaný)
A takovyhle material ma "bronzovy podporovatel" a nejvic lajku? Jen kvuli tomu ze lidi predtim neumi ani precist o cem pisu? Ze nekomu nedojde ze hlavnim cilem tech specializovanych reseni je aby request neprisel v kontaktu s OpenSSL implementaci? Ze obecny ramec zranitelnosti je uz davno znam a reseni existuji snad dele nez 15 let?
Na specializovanou proxy(kus HW , v HW zadratovano SSL/TLS/PKI - vetsinou ten cert je i na PKI karte )dorazi request v https komunikaci a odsud to leze uz http nebo prebalene do neceho jineho. Paranoidni firmy a bezpecnostni agentury uzivaji i treba ipsec pro vnitrni sit nebo blize neoznacene sifrovaci sitovky.
Fakt nechapu. Zaklady vyvoje architektury, reseni uz nekdy z dob pred expandia bankou kdyz se zavadela prvni bankovnictvi.
-
Trident (neregistrovaný)
Ano obcas tak to maji. Je to vetsinou v trusted zone datacentra, ktera je prisne monitorovana bankou a dle bezpecnostnich pozadavku musi byt zvlast oddelena. Toto neni bezny hosting. Pokud mas totiz pristup k HW, tak tu masinu stejne z venci muzes napadnout minimalne pres seriovou servisni konzoli pokud obejdes okolni bezpecnostni mechanismy jako tampery a znas docasne pridelene heslo admina. To ovsem uz po par pokusech budou rincet alarmy z IPSky protoze vsechno se loguje bokem na jinou masinu a monitorruje realtime. A neni to opravneny zasah technika
No a budes se divit ale SANka vetsinou neni sifrovana takze kdyby ses na nej napichnul tak si muzes cist binarni db soubory.Vlastne ani prenosy po sbernicich nejsou sifrovane. Krom toho servery muzes hacknout pres usb, no nastesti nepouzivame hovadskou x86 architekturu.Jestli te to uklidni tak naprosto bezne si snifuju pres port monitoring komunikaci mezi balancerem a masinami kdyz se vyskytne nejaky problem. Mezi tim jde videt naval jak prichazeji tydenni platy. Samozrejmne ma akce je zalogovana na X urovnich a dle ITILu trackovana.
Proto pisu. Neres a neprepinej. Mira rizika je akceptovatelna. Mnohem horsi je zabezpecit masiny tajnych sluzeb. Tam se totiz musi pocitat s aktivni snahou ziskat strategicke informace za kazdou cenu.
Strasne blbe je to kdyz mas cmoudovou banku. Vsechno musi byt sifrovane na vstupu i vystupu a jen jakysi certifikat providera ti dava jistotu ze maji cmoud bezpecny. Takze pak dopadas tak ze mas sifrujici sitovky a pod tim jeste sifrujes na urovni IP nebo HTTP. Nicmene stejne mas zranitelne systemy v mistech kde se rozsifrovava. Tam stejne musis udelat caru a mit tam pomyslnou trusted zonu. Howgh.
-
Filip JirsákStříbrný podporovatel
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).
