Názory k článku
SSL v ohrožení: komunikaci je možné dešifrovat

<cite>Google se nyní ve vývojové verzi svého prohlížeče Chrome snaží útoku bránit tím, že náhodně fragmentuje přenášená data do více šifrovaných bloků.</cite>
Raději kdyby tam nacpali novou verzi TLS jako to má Opera a IE a vzápětí i do svých služeb gmail a Google+ tak by udělali mnohem lépe.

Mistr Hůlka si doplní základní vzdělání.
Nejde o to jestli prohlížeč podporuje nové TLS. Když ho nepodporuje proti strana. Postup který zvolilo Chrome je dobrý pro starý protokol.
Googlu jde prostě o to aby uživatel jejich prohlížeče byl co nejvíc v bezpečí i když majitel serveru na to s--e.

Kdyby si lidi aspoň četli, na co reagují, a že jejich námitka byla zodpovězena ještě dřív, než ji vůbec podali.

cituji:
"Jakmile dojde na spojení se zajímavým serverem, útočník podstrčí klientovi vlastní javascriptový kód například v přidaném iframe nebo přímým vložením do stahované stránky. Tento skript se postará o manipulaci šifrovacího algoritmu, který začne generovat slabě šifrované bloky."
-- docela by mě zajímalo, jak může útočník injectnout JS kód do aktivního TLS streamu, aniž by to klient zjistil.

S tím také souvisí odstavec z TheRegister:
"Duong and Rizzo said the underlying vulnerability BEAST exploits is present in virtually all applications that use TLS 1.0, making it possible to apply the technique to monitor private communications sent through many instant messenger and Virtual Private Networking programs."
-- to znamená, že bychom teoreticky mohli zavrhnout OpenVPN, ale opět - na čem sakra tento útok staví? Na exploitu javascript engine současných browserů? To pak není chyba TLSv1.0, ale spíš toho JS engine (tím nechci říct, že nejsem pro TLSv1.2). Pokud je web browser podmínkou, tak jistá část OpenVPN trafficu je snad v bezpečí. Pro takovéto případy by měl být ipsec jednou z pojistek.

Nebo je celá tahle kauza další bublina typu "certifikační autority" a technologie jako taková kompletně prolomena nebyla (ač byla dokázána teoretická možnost při donucení klienta generovat slabě šifrované bloky)?

Taky mi přijde, že javascriptem pouze vyměnili asymetrickou šifru za jeden klíč a jeden klíč už se rozluštit dá. Samotné SSL, tak jak je například v SSH, je v bezpečí, ne?

presne to iste napadlo aj mna. ako inak podstrcit do html kodu daky javascript? do sifrovanej https snad nie, ved tu idu prave pomocou toho JS rozbit.
vyzera to tak. alebo sme mimo obaja. :-)

ja by som ten JS podstrkoval z darebackeho reklamneho servera.

pravda, externe data su vzdy riziko. uvazoval som len nad ibankingom, ale fakt je, ze freemaily ziju prave z reklamy.

Jenze i na webech banky mate casto nesifrovane prenasene soucasti, coz samo umoznuje tam neco takovyho vlozit. A dost casto banka jednoduse bez povolenyho scriptovani nefunguje.

Tiez mi to tak zatial pripada.

protokol založený na asymetrickém šifrování (např. AES)...

Odkdy je AES asymetrický algoritmus?

precitaj si to este raz a ak nepomoze, tak este raz, az pokial na to neprides...

Zatím nejsou podrobnosti zveřejněny, ale já to chápu tak, že se to nepodstrčí do TLS, ale úplně na začátku. Představuji si to asi tak:

Počítač se snaží připojit na IP adresu GMailu. Já jako MITM mu podstrčím normálně nešifrovanou HTML stránku, což udělat můžu, protože TLS spojení ještě nebylo navázáno. V té mé stránce je ten JavaScript a velký iframe, ve kterém se teprve načítá správný Gmail.

Tak teď jsi to možná ještě víc zamotal.

Pokud prohlížeč komunikuje s https, tak tam dojde k ověření certifikátů (nejlépe obou stran, ale přihlašování pomocí certifíkátů ještě není tak rozšířené) a až po tomto ověření se komunikuje.

Ve článku je MITM popsán jako triviální krok. Ano, pokud někdo dokáže úspěšně udělat MITM, tak už si s tím streamem může dělat co chce. Ale základem SSL je nepřipustit ani ten MITM.

Ale to jsou jen spekulace, snad budou úplně informace co nejdříve.

Já ale říkám, že by to proběhlo ještě před navazováním šifrovaného spojení. Když zadám do prohlížeče "www.gmail.com", tak jak ví, že má přijít SSL handshake? On netuší, že si přeju šifrovat. Prostě mu jako odpověď přijde nešifrovaná stránka, zdánlivě od toho správného serveru. On ji přijme a je zobrazí.

A neni pak lepsi podstrcit stranku ze ktere si prectu uzivatelovy prihlasovaci udaje nez podstrkavat kod na lamani SSL?

To me presne napadlo taky.

Nie, pretoze nikdo nebude zadavat prihlasovacie udaje do systemu, ktory normalne bezi na HTTPS, do obycajnej HTTP session. Browsery to imho zobrazuju dost zretelne.

to byste se divil

Ale vy nemuste chtit vedet neci login, jsou i zajimavejsi informace a muzou byt o to cenejsi, pokud dotycnemu nedate sanci zjistit, ze neco neni vporadku.

IMO je to jak tu je zminovano zalozeno na tom, ze dotycny nejdriv leze na nesifrovanou http stranku. Pokud zada primo https adresu, tak si napadeni (predevsim to vlozeni scriptu) dokazu predstavit jen v pripade, ze ta stranka obahuje napriklad obrazky, odkazovane pres http.

"v pripade, ze ta stranka obahuje napriklad obrazky, odkazovane pres http"

Na což opět upozorní browser. Na "https" stránkce musí být přes https s platným certifikátem všechno. Tedy i obrázky a skripty.

Ale SSL komunikace přece začíná před jakýmkoli HTTP, ne? .. Vizte ten známý problém "slepice a vejce" s Host fieldem / SSL (a *nemožností* použít SSL pro virtual apache servery). Pochopitelně pokud stránka vynutí plaintext před samotným SSL, tak by tu byla možnost.

Jeho příspěvek byl pořád ještě hodnotnější než tvůj.

Ehm, snad https://www.gmail.com/

Pokud někdo očekává od www.gmail.com (by default http) nějakou bezpečnost, tak je ten bezpečnostní problém úplně jinde.

Nebo si nerozumíme?

Raději od začátku:

URL: https://www.gmail.com/

Prohlížeč si ověří certifikát serveru. Pokud nikdo neukradl soukromý klíč ze serveru a certifikát sedí, má klient jistotu, že je připojen přímo na server, kde chce být.

Naváže se SSL tunel pomocí symetrické šifry (klíč je domluvený přes nesymetrickou).

Proudí HTTP data.

Ve které fázi útočník "prolomí" ono SSL? Je to útok z venku na ono domlouvání symetrického klíče? Ale jak, bez znalosti soukromého klíče?

Nejsem expert přes šifrování, ale podle mě je tu možnost podstrčit nějaká data při tom asymetrickém domlouvání. Útočník sice nezná soukromý klíč klienta, ale už z principu zná jeho veřejný klíč a tedy může poslat šifrovanou zprávu. Což ovšem neumožňuje podstrčit iframe, protože stránka se načítá až v symetricky šifrovaném tunelu...

Já si myslím, že by člověk musel asi vidět tu přednášku, z krátkého článku těžko něco vymyslíme :)

Mozna jde o to, ze utocnik castecne zna plain text => on vi ze klient posle HTTP request a taky vi co posle HTTP server v odpovedi. Sifrovany obsah ma take k dispozici. Sifrovaci klic proc AES se v prubehu komunikace meni. Je mozne, ze nejak dokazou uhadnout klic na zaklade znalosti plaintextu i sifrovaneho obsahu.
Tzn. nejedna se o prolomeni AES, ale o uhodnuti klice pro AES.
Prvni blok SSL komunikace nebyl dostatecne nahodny => nemam dostatecne nahodny klic pro druhy blok.

Podobne jako kdyz v debianu pouzili jako seed PID procesu a nedoslo jim, ze 65 tisic kombinaci se da snadno rozkousknout.

Ono by stačilo místo CBC použít CTR. I když teoreticky se to snadno řekne, ale praxe je horší.

Takže podľa teba by bolo vhodné do HTML výstupu pridávať náhodné znaky (napríklad ako HTML komentár)?

Je celkom možné, že ten podstrčený JavaScript opakovane posiela na server známy obsah a týmto spôsobom zvyšuje šancu na uhádnutie kľúča. Rovnako môže zabezpečiť posielanie známeho obsahu zo servera. Napríklad posiela požiadavku na obrázok cez HTTPS, pričom obsah takejto odpovede pozná.

Možno by ako ochrana stačilo na strane serveru náhodne meniť mieru kompresie výstupu a zapnúť to aj pre statický obsah (obrázky, súbory)...

Uhodnutí klíče ze znalosti otevřeného a šifrovaného textu by znamenalo prolomení dané šifry.

To myslím nebude tento případ.

Cet ste to? Ten sifrovaci klic se voli na zaklade !obsahu! => pokud vygenerujete dotatecne stejny obsah, budou jednotlive pakety sifrovany stejnym nebo velmi podobnym klicem. Dosahnete tim toho, ze prostor klicu, ktere musite prohledat a otestovat zmensite o mnoho radu => dostavate se do onech 10 minut.

X-Frame-Option: Deny

No já jako nejpravděpodobnější scénář vidím toto: JS se podstrčí do nějaké nešifrované stránky (může to být http://www.seznam.cz). JS naváže TLS spojení s https://mail.google.com (aniž by se přihlásil ke schránce) a protože má spojení ve své moci, pošle si jím potřebná známá data. Uživatel mezi tím surfuje někde jinde, zatím co se na pozadí podaří útočníkovi rozšifrovat to TLS spojení iniciované JS. Když potom stejný browser přistoupí na https://mail.google.com na popud uživatele, použije prohlížeč již otevřené (a rozšifrované) spojení.

Na blogu Bruce Schneiera vysly nejake dalsi hinty
http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html

Přesně. Naprosto souhlasím. :)
Možnost modifikace http response streamu je možná mimo ssl nebo i v ssl tunelu, ale tam jen při znalosti šifrovacího klíče, který se mění.
Ale jak říkáte, patrně ten útok staví na exploitu JS a informaci, že bloky o nízké informační hodnotě oslabují SSL.
Pánové to patrně asi ani nebudou demonstrovat, možná chtějí jen na sebe upoutat pozornost. Doufám, že redakce bude informovat o tom pokusu v dalším článku. Docela by mě zajímal výsledek.

Problem je, ze to zlepsovanie stoji peniaze, zhorsuje uptime sluzieb, v tomto pripade aj potrebuje viac elementarnych-operacii.

A navyse uzivatelom je to jedno, ti maju napisane v browsri ze stranka je bezpecna, takze asi bezpecna bude vsak ano :)

I v případě, že máme originální data, tak je časově nereálné hrubou silou AES prolomit. Tyhle protokoly jsou koncipovány s tím, že některá jejich část bude kompromitována (což se stalo teď), ale bezpečnost bude i tak zajištěna. V praxi to znamená, že do budoucna se to nemůže používat, ale neznamená to, že je nyní ohrožena bezpečnost.

Někde jsem četl o prolomení AES pomocí GPGPU na grafické kartě (bylo to v souvislosti s prolomením zabezpečení WPA-AES WiFi sítí). To že se považuje za časově neudržitelné prolamování BruteForce útokem ještě neznamená, že je to jediný typ útoku (v případě AES jde významně omezit počet kombinací rotací vektorů nad šifrou...ale jak to už si nepamatuju).
Nicméně výpočetní výkon grafických karet přesahuje asi 20 násobně výkon nejlepších procesorů a v masivním paralelizmu si libují. Každým rokem se jejich výkon téměř zdvojnásobí -> snižuje čas potřebný na prolomení...to dohromady znamená, že každá šifra je dříve či později prolomitelná a musí se nahradit lepší.
http://www.lupa.cz/zpravicky/wpa-lze-pry-snadno-prolomit-jiz-za-ctvrt-hodiny/

Pokud je mi známo, tak AES používá WPA2, která prolomena nebyla. Kompromitovaná WPA používá dočasné klíče. Navíc žádné možné výrazné snížení počtu kombinací u AES také zjištěno zatím nebylo (nevím, jestli si to nepletete s DES, ale tam je taky problém jen s krátkým klíčem + slabé klíče, ty ale u AES nejsou). Další věcí je výkon GPGPU, který je víceméně mýtický a hlavně problematícký u celočíselných operací (GPGPU jsou nejsilnější na 32b float).

AES je v současnosti považováno za bezpečné tzn. že prolomení hrubou silou by trvalo miliony let, navíc AES podporuje až 256b klíče a to už nemá smysl řešit vůbec.

neví jestli je to věrohodný zdroj: https://mocana.com/blog/2011/08/19/new-aes-attack-faster-than-brute-force/

původně jsem to četl jinde, ale nemám čas to hledat

No, tří- až pětinásobné zrychlení oproti hrubé síle znamená, že se 128-bitová šifra degraduje na 126 bitů. To AES moc neohrozí...

S tím výkonem GPGPU se mýlíte, jsou nejrychlejší právě v celých číslech.

nejak mi tam nesedi ta ssl cookie a m-i-m. ssl cookie jsou nahodny data co jdou nesifrovane protokolem jeste pred key exchange, takze si je muze precist kdokoliv. a pokud jde a dal uz je to cele mismas s tou nizkou entropii. leda, ze by na zaklade te predvidatelnosti plaintextu od zacatku a znalosti ssl cookie dokazali ziskat session key nejakym znamym utokem na cbc, ktery byl doted povazovany za nerealizovatelny a pak si precist zbytek co nasleduje a zabranit jeste nejak i pripadnemu rekey, aby byli schopni docist az do konce.

http://article.gmane.org/gmane.network.openvpn.user/32566

A asi na tom bude něco pravdy, když @thaidn tvrdí, že už dříve poskytli údaje o BESTII většině vývojářů SSL.

http://www.insecure.cl/Beast-SSL.rar

Nakonec to dělají ještě jinak: Javascript se vloží do nezabezpečené stránky typu www.seznam.cz a začne hned útočit na SSL server: přinutí prohlížeč, aby se připojil na pozadí k "https://mail­.google.com" a posílal vybrané otevřené texty, prohlížeč přitom v requestu pošle i session cookie, kterou se touto technikou podaří rozluštit.

Autoři ukazují, že útok na SSL pomocí vybraných otevřených textů (na jeho předvídatelnou volbu IV pro sérii CBC bloků), je už známý několik let, ale zatím jej nikdo neuměl efektivně nasadit do WWW prohlížeče.

V tom případě by jako ochrana mělo stačit, aby prohlížeč otevřel jedno SSL spojení pro požadavky JavaScriptu z cizí stránky (ten podvržený na nezašifrované stránce) a jiné SSL spojení pro požadavky z panelu, kde si uživatel otevřel GMail.

Útočník zde neukradne "session cookie", to jsem napsal špatně, ale "login cookie" - tu, která zajišťuje, že při přístupu do Gmailu nemusí uživatel stále zadávat heslo (stálé přihlášení). A tuto cookie prohlížeč pošle i pokud do Gmailu přistoupí Javascript bez vědomí uživatele. Získá tak přístup ke schránce do té doby, než uživatel někde zmáčkne Odhlásit nebo než algoritmy Google samy změní login cookie, jak to občas udělají. Ale to mohou být dny i týdny.

Ještě poznámka: Gmail je jednou z velmi dobře zabezpečených služeb, tam lze login cookie získat jedině takto obtížně, protože šifruje pomocí SSL celou session. Na rozdíl od Seznamu, Yahoo a spol., které šifrují jen přihlašovací formulář, takže je login cookie vidět i obyčejným tcpdumpem. Už na to mockrát odborníci na bezpečnost upozorňovali...

Nemůže to udělat jako AJAXový požadavek a přečíst si odpověď serveru – viz Same origin policy – ale může zařídit načtení např. nějakého obrázku jako pozadí.

To je popsáno v odkazovaném textu, věnuje se tomu celá jedna část. Ochrany cross-site skriptování jsou účinné hlavně proti vzdáleným útočníkům, kteří nemají MITM přístup. Pokud má útočník přístup MITM (může vidět a ovlivňovat data mezi prohlížečem a serverem), tak mu to hodně pomůže -- je tam například zmiňováno, že někdy stačí zajistit, aby (s odkazem na předchozí příspěvek) měly servery www.seznam.cz a mail.google.com stejnou IP adresu (z pohledu prohlížeče - DNS spoofing, NAT).

Ad „A tuto cookie prohlížeč pošle i pokud do Gmailu přistoupí Javascript bez vědomí uživatele.“

To je pravda. Pokud útočník krade cookie a ne jméno a heslo, tak to nepomůže.

Ad „Na rozdíl od Seznamu, Yahoo a spol., které šifrují jen přihlašovací formulář“

Tohle jsem nikdy nechápal, přijde mi to jako fatální chyba. Útočník se dostane ke schránce oběti a tam nejde jen o čtení nějakých banálních osobních e-mailů, ale o to, že přes ni získá přístup k dalším službám uživatele (vyžádá si hesla, nebo si na něj třeba pořídí SSL certifikát).

P.S. prosím redakci o smazání duplicitního komentáře níže.

Nejsem odborník na bezpečnost, ale mám pocit, že Javascript se stranky jedna.cz nemuze nacist na pozadi stranku z jineho serveru napr. dva.cz
Nebo to nějak jde?
Díky

Nemůže to udělat jako AJAXový požadavek a přečíst si odpověď serveru – viz Same origin policy – ale může zařídit načtení např. nějakého obrázku jako pozadí (z cizí domény).

Nemůže to udělat jako AJAXový požadavek a přečíst si odpověď serveru – viz Same origin policy – ale může zařídit načtení např. nějakého obrázku jako pozadí (z cizí domény).

Zde je poměrně slušně naznačeno, jak útok probíhá, a jak by mu šlo předejít:

Security impact of the Rizzo/Duong CBC "BEAST" attack

Kdyby se článek jmenoval "Zajímavý útok na SSL v kombinaci s javascriptem" tak by asi bylo méně nejasností...

co jsem slyšel, tak nakonec použili java plugin, potřebovali nějak obejít same-origin policy, což se jim jen s javascriptem nedařilo, ale zato se jim podařilo v JVM objevit díru, kterou potebovali

co jsem slyšel, tak nakonec použili java plugin, potřebovali nějak obejít same-origin policy, což se jim jen s javascriptem nedařilo, ale zato se jim podařilo v JVM objevit díru, kterou potebovali