it-swarm-eu.dev

Existuje způsob, jak zmírnit BEAST bez úplného vypnutí AES?

Zdá se, že nejjednodušší způsob, jak chránit uživatele před útokem BEAST na TLS <= 1,0, je upřednostnit RC4 nebo dokonce úplně zakázat všechny ostatní (CBC) sady šifrování, např. zadáním něčeho podobného

SSLCipherSuite RC4-SHA:HIGH:!ADH

v konfiguraci mod_ssl Apache.

Zdá se však, že problém s CBC byl vyřešen v TLS> = 1,1; existuje nějaký způsob, jak (znovu) povolit tyto šifry pro klienty, kteří tvrdí, že podporují TLS 1.1 nebo 1.2? Zdá se, že existuje řešení:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

který provede trik zadáním šifrových sad, které jsou k dispozici pouze v TLS> = 1.1. Zdá se, že to má vedlejší účinek, protože brání klientům TLS> = 1,1 používat některý ze „starších“ šifrovacích sad.

Neexistuje opravdu způsob, jak explicitně říct mod_ssl, aby používal šifry v režimu CBC pro TLS> = 1,1, ale pouze RC4 pro SSL/TLS <= 1,0? Zdá se, že se jedná o optimální kombinaci zabezpečení a kompatibility.

24
lxgr

Jedním ze způsobů, jak zmírnit BEAST, je nedělat nic . Stává se tak, že ačkoli zranitelnost použitá v BEAST stále existuje, její zneužití je poměrně obtížné. Vyžaduje schopnost provádět požadavky napříč doménami, s vysokou úrovní kontroly nad daty, které jsou v žádosti zasílány; potřebuje zejména „binární“ data. Duong a Rizzo nenašli způsob, jak zmapovat útok na pláni <img> tagy (nepřátelský Javascript, který takové tagy produkuje, s cestou zvolenou útočníkem: cesta se dostane do požadavku, ale je pouze textová). Ve své demonstraci mohli použít dvě mezery mezi doménami, jednu v pracovní verzi WebSockets, druhou v implementaci Java od společnosti Oracle. Obě díry jsou od té doby opraveny, proto mají pravdu nyní BEAST již neplatí (pokud jste neaktualizovali svůj prohlížeč déle než jeden rok, v tom případě máte pravděpodobně větší problémy).

Protože spoléhání se na neexistenci zranitelností napříč doménami je přinejlepším chabé, prodejci prohlížečů také zahrnuli některá další protiopatření, s rozdělení záznamů . Když prohlížeč chce odeslat blok n bajtů dat, namísto toho, aby je vložil do jednoho záznamu SSL, rozdělí je do záznamů dva, první být velmi malý. Hranice záznamu nemají v SSL/TLS žádný sémantický význam, takže můžete provést takové rozdělení beze změny významu. Každý záznam však končí MAC vypočteno z dat záznamu a pořadové číslo a pomocí jednoho klíče odvozeného od počáteční výměna klíčů. To nějak funguje jako generátor pseudonáhodných čísel. Proto malý záznam „emuluje“ náhodnou IV generaci, díky které je TLS 1.1+ imunní vůči BEAST.

Ideálně by rozdělení bylo 0/n: záznam bez dat (ale stále s MAC), následovaný záznamem se skutečnými daty. Záznamy s nulovou délkou jsou povoleny (podle standard ), ale implementace buggy klienta a serveru je netolerují (zejména IE 6.0)), prohlížeče místo toho používají 1/n-1 split, což je stejně dobré pro porážku BEAST, ale funguje také s téměř všemi stávajícími klienty a servery SSL/TLS. Alespoň Chrome a Firefox to posunuli minulý rok .

Dobré řešení je TLS 1.1 + , ale i na SSL 3.0 a TLS 1.0 lze problém BEAST považovat za vyřešený, alespoň ve webovém kontextu. Proto používejte AES a buďte šťastní.

15
Thomas Pornin

OpenSSL má zmírnění pro BEAST , které bylo ve výchozím nastavení povoleno od 0.9.6d, pokud je vaše verze OpenSSL tato verze nebo novější a nenastavili jste SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS není třeba omezovat šifry ani deaktivovat TLS 1.0.

10
mgorven

Chápu, že TLS <1.1 s jakoukoli blokovou šifrou v režimu CBC je náchylný k BEAST. Podle mého názoru jsou opět jedinou možností použít TLS 1.1 nebo vyšší nebo použít proudovou šifru.

Nebo samozřejmě můžete použít jiný protokol, který není ovlivněn BEAST, jako SSH :)

0
atk