Hlavní navigace

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,...

  • Článek je starý, nové názory již nelze přidávat.
  • 27. 2. 2017 17:55

    Filip Jirsák
    Stříbrný podporovatel

    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é.

  • 27. 2. 2017 22:38

    Ondřej Caletka
    Zlatý podporovatel

    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.

  • 28. 2. 2017 7:21

    Filip Jirsák
    Stří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í.

  • 28. 2. 2017 23:25

    . . (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ě.

  • 1. 3. 2017 11:10

    Filip Jirsák
    Stří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.

  • 1. 3. 2017 0:38

    Kaacz (neregistrovaný)

    SSL/TLS zakončení se řeší jinde.. Možná to tak děláte ve státní správě, ale je to blbě. :)

  • 28. 2. 2017 4:22

    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.

  • 28. 2. 2017 7:14

    Filip Jirsák
    Stří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…

  • 1. 3. 2017 0:25

    Kaazc (neregistrovaný)

    Z reakcí mi připadá, že ti nic neříká něco jako "terminace ssl na balanceru". Smutné pro někoho takového... :)
    Ale státní správa je plná lidí bez vzdělání... :)

  • 1. 3. 2017 0:36

    Kaacz (neregistrovaný)

    Klíč nikde na serveru NENÍ, protože na server přijde už jen http.proberte se, tohle není domácí server. :)

  • 18. 3. 2017 12:18

    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.

  • 1. 3. 2017 0:31

    Kaacz (neregistrovaný)

    Hlavně se neterminuje SSL na serveru!
    Terminaci (offload) SSL/TLS dělá balancer za všechny servery (šetří to peníze za certifikáty) a pak to v http pošle na farmu serverů.
    Takže si vsichni ušetřete kydy kolem ssl v tomto případě... :)

  • 1. 3. 2017 9:33

    MP (neregistrovaný)

    Vazne? Takze maji veskery provoz mezi balancerem a farmou nesifrovany, takze jakkykoli sniffer si odtamtud muze vytahnout co chce? Navic, kde to setri penize za certifikaty? Vzdyt certifikat na domenu je uplne jedno kde je, stoji jen jednou.

  • 18. 3. 2017 12:41

    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.

  • 1. 3. 2017 0:35

    Kaacz (neregistrovaný)

    Záporné palce dala ho*ada, která netuší, jak to u takových služeb funguje. Samozřejmě že SSL/TLS je zakončeno na speciální krabičce s HW akcelerací dávno před serverem. :)

  • 1. 3. 2017 10:52

    Filip Jirsák
    Stří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).

  • 1. 3. 2017 0:28

    Kaacz (neregistrovaný)

    Proboha! Kdo na takovéto (i nižší úrovni) terminuje SSL na serveru?! Nikdo! :)

  • 1. 3. 2017 0:32

    Kaacz (neregistrovaný)

    Úplnej mimoň. SSL se terminuje jinde. Tohle není domácí server.. :)