Logjam, nová zranitelnost TLS

Zranitelnost pojmenovaná Logjam se týká protokolu Transport Layer Security (TLS) a může být zneužita v pozici Man-In-the-Middle (MitM) k downgradu na 512-bit klíč. Útočník může využít chybu ke čtení šifrovaných dat, případně k manipulaci s těmito daty. GnuTLS je v pořádku. [CSIRT.CZ]

21.5.2015 00:29 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[pavlix]

To ale není zranitelnost TLS, že?

[xm]

On ještě někdo v nastavení webserveru nechává povolené slabé EXPORT šifry?

[Max]

Ano.
Zdar Max

[xm]

No to je ovšem hodně smutné Všichni by si povinně měli nastudovat články na Qualys SSL Labs a kdo neprojde SSL Server Testem na A+, ten by raději neměl vůbec provozovat webserver

[xm]

Jinak jen pro zajímavost - třeba abclinuxu.cz má extrémně špatné hodnocení C. Podporuje pouze zastaralé TLS 1.0 (nikoliv 1.1 a 1.2), u hromady referenčních browserů nepodporuje PFS (perfect forward secrecy), podporuje slabé šifry jako RC4 (a obecně EXPORT šifry), intermediate certifikát používá SHA1... a asi by se ještě dalo pokračovat

[Jendа]

podporuje slabé šifry jako RC4 (a obecně EXPORT šifry)

To je snad problém klienta, ne?

[xm]

Už jenom to že server RC4 či slabé EXPORT šifry podporuje je chyba. Server si má vynucovat preferované pořadí šifer a slabé vůbec nemá povolit.

[Jendа]

Už jenom to že server RC4 či slabé EXPORT šifry podporuje je chyba.

Taky podporuje HTTP… Šifru vybírá klient a je na něm, aby si vybral tu nejlepší co umí.

Server si má vynucovat preferované pořadí šifer a slabé vůbec nemá povolit.

A klienti kteří nic lepšího neumí nebudou šifrovat vůbec (než aby šifrovali alespoň slabě).

[xm]

Když se připojím přes obyčejné HTTP, jasně vidím, že jsem připojen nešifrovaně a počítám s tím.

Když se ale připojím přes HTTPS, očekávám, že to šifrované spojení bude skutečně bezpečné (alespoň v rámci našich aktuálních nejlepších znalostí, vědomí a svědomí ). V kombinaci s HSTS a HPKP mi nehrozí ani SSLstrip či falešný certifikát, byť podepsaný "důvěryhodnou" CA (alespoň tedy pokud jsem stránky už někdy v minulosti navštívil).

Né nadarmo se říká, že spatné šifrování je horší než žádné šifrování (protože vyvolává falešný pocit bezpečí).

[xm]

Obecně doporučuji kouknout např. na Cipherli.st, kde je doporučované nastavení pro různé nejpoužívanější servery (Apache, nginx, Lighttpd, Postfix, Dovecot, atd.). Osobně používám poněkud jinou (sofistikovanější) ciphersuite, ale jako základ a pro orientaci jsou to dobré stránky.

[Jardík]

Celý TLS je postavený na palici a závisí na důvěryhodnosti vyvolených jakýchsi certifikačních autorit, co si můžou vydávat certifikáty, jak chtěj. A tento důvěryhodný list vám vnucují správci distribucí či vývojáři prohlížečů, aniž by se vás ptaly, jestli souhlasíte. A je velmi obtížné v některých případech všechny vyhodit. V základu by mělo být 0 takových autorit a uživatel sám by si měl důvěryhodné autority zvolit sám (pokud takové existují, když všechny souhlasí s monopolem USA na doménová jména a neřídí se alternativními DNS servery).

[xm]

To částečně řeší HTTP Public Key Pinning (HPKP) (princip stejný jako u SSH - předpokládá se, že při prvním připojení k danému serveru je toto připojení důvěryhodné). Nic lepšího na současném webu prostě nevymyslíš, vždycky budeš muset někomu (alespoň někdy) důvěřovat.

[Tomáš2]

ano, PKI má svoje slabiny v nutnosti mít centrální autoritu/autority, zatím to je ale opravdu to nejlepší, co je v tomhle prostředí k dispozici.

Je naprostá blbost a hlavně neznalost problematiky tvrdit, že nejlepší je si nechat uživatele zvolit autority, kterým věřím. Podle čeho by takovou volbu měl provést? Jak si dokáže ověřit, že autoritě chce věřit a není to nějaký podvodník? Představ si situaci, kdy vir/antivir/operační systém/program ti nabídne věřit svojí autoritě, pojmenovat si jí může jakkoliv, podle čeho bys rozhodnul? Jak by dokázal uživatel rozeznat desítky CA, které v současné době jsou k dispozici? Nebo bys ho nechal volit konkrétní certifikát při první návštěvě webu? Jak bys řešil renew a rozeznání renew od podstrčeného certifikátu?

[xm]

Nebo bys ho nechal volit konkrétní certifikát při první návštěvě webu? Jak bys řešil renew a rozeznání renew od podstrčeného certifikátu?

Zrovna tohle tedy HPKP řeší... včetně například ztráty/zcizení soukromého klíče. Spolu s fingerprintem aktuálního veřejného klíče se posílá i fingerprint záložního veřejného klíče, který musí mít majitel serveru samozřejmě někde bezpečně uložený (a těch záložních otisků se může pinnovat více).

[Sinuhet]

Pokud je možné všechny autority vyhodit a nahradit je vlastními, nemám s tím problém. Naopak, jsem rád, že tento výběr někdo dělá za mě, a že jsou lidé, kteří jsou natolik paranoidní, že i tento výběr je podroben kritice. Např. u Gentoo bych takovou funkcionalitu očekával.

Samozřejmě nic nebrání tomu, aby vznikla další distribuce, která v defaultu žádnou důvěryhodnou autoritu mít nebude :)

[biolog]

To nic není, můj zaměstnavatel má F. A to prosím správce při nastavování toho serveru postupoval podle návodu, takže se nemohl jen tak splést.

Na běžné zabezpečení by návod přece neměl být potřeba.

[Jendа]

To nic není, můj zaměstnavatel má F.

Tak záleží za co. Jednu dobu třeba dávali špatné známky za to že jsi neměl podpis od jimi uznávané "autority".

[portsnap]

He he. Já jsem dostal T. Kdo z vás to má?

[mirec]

Čo majú všetci proti self signed certifikátom? Ja sa ako certifikačná autorita uznávam. Ak ignorujem to že je to self signed tak C.

[Jendа]

Já. Ale pod tím máš napsánu skutečnou známku.

[mseed]

If trust issues are ignored: A

[xm]

Btw. podle některých informací to vypadá, že tohle je zranitelnost kterou NSA používá k prolamování VPN.

[dve rozpulene zizaly]

VPN postavena na TLS/SSL je pro mentalni anorektiky.

[xm]

A to jako proč? Správně nastavená OpenVPN je prakticky bezpečnější než cokoliv jiného a hlavně projde všemi firewally (na rozdíl od IPsec).

[dve rozpulene zizaly]

Prvni cast tvrzeni by se dala preformulovat jako "pri spravnem pristupu muzeme kamenolom obsluhovat i trakarem". Druha cast tvrzeni je prinejmensim irelevantni a nezaslouzi si pozornost.

[Sid]

Hm... nejaky manual ktory by rozsifroval co chcel autor zvestovat?

[bigBRAMBOR]

druha čast je prave dnes velmi dulezitá, s ohledem na to co jsou schopni někteří operatori nabidnou jako internet.

[xm]

IPsec na tom není o nic lépe, NSA dokáže ve velkém IPsec s IKE/ISAKMP dešifrovat (viz Snowdenovy dokumenty), má na to infrastrukturu a zaběhlé postupy, provádí to podle všeho relativně běžně.

OpenVPN funguje skvěle a nastavit jí správně není vůbec problém. Navíc jak jsem psal mnohem lépe prochází firewally, což _je_ relevantní (k čemu mi je VPN, pokud se k ní pak někde nemohu připojit).

[Jendа]

IPsec na tom není o nic lépe, NSA dokáže ve velkém IPsec s IKE/ISAKMP dešifrovat (viz Snowdenovy dokumenty), má na to infrastrukturu a zaběhlé postupy, provádí to podle všeho relativně běžně.

V odkazovaném dokumentu se píše, že umí IPSec dešifrovat pokud znají klíč (četl jsem to zběžně). To umím s kdejakým protokolem taky.

[xm]

Ano, ale v jiném dokumentu (nebo možná i někde v tomhle, už si přesně nepamatuji) bylo trochu vidět jak klíče získávají a plynulo z toho, že pro ně není problém získat takto i klíče z bank, atp. (zrovna nějaká banka tam byla myslím jako příklad). Prostě díry v koncových IPsec zařízeních, hlavně nejspíš hardwarových.

Nikde jsem nepsal že umí IPsec lámat obecně, pouze že na to mají infrastrukturu a běžně ho dešifrují (ano, nejdřív ale získají klíče). Zajímavé pojednání nad tím bylo v tomto článku. Což je ale obecně takto v praxi horší případ než s OpenVPN a o to mi tu šlo (dotyčný na koho jsem reagoval se tvářil jako by snad OpenVPN bylo neprofesionální řešení... přitom "profesionální" nasazení IPsec právě NSA dešifruje).

[Jendа]

Prostě díry v koncových IPsec zařízeních, hlavně nejspíš hardwarových.

Jo, to jsem taky viděl. Ale když máš díru v zařízení, je ti jedno, jestli si přečteš klíč OpenVPN nebo IPsecu…

[martin]

ve skutecnosti ji pouziva GRU k prolamovani ukrajincu pri vyslesich