Názory k článku SSL v ohrožení: komunikaci je možné dešifrovat
-
Hulka (neregistrovaný)
<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. -
webdev (neregistrovaný)
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. -
Hulka (neregistrovaný)
Schopnost logického uvažování a porozumění odborných souvislostí nemá nic společného se základním vzděláním - ani jedno vás na základním stupni nenaučí ;-). Dále je mi znám základní princip tvorby šifrované komunikace pomocí SSL/TLS. Znovu si přečtěte můj prvotní komentář. Za druhé jsem pouze vyslovil, že snaha Googlu o své vlastní řešení k co nejvýraznějšímu potlačení rizika úspěšného útoku mi připadá jako plýtvání prostředky a časem, tedy kromě marketingového efektu, že Google Chrome patří mezi nejbezpečnější webový prohlížeč pro širokou masu uživatelů.
-
Jiří J. (neregistrovaný)
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)?
-
ja to chapu tak, ze javascriptem tam generuji nejake ta "znama data" na jejichz zaklade jsou schopni to pak prolomit.
ale jestli to chapu spravne, tak ten javascript muzou injectnout jen pres HTTP, takze pokud jdu rovnou na https, tak to nepujde, nebo?
(na spoustu webu ale chodite http a az prihlasovaci form vas odesle na https) -
Jiří J. (neregistrovaný)
Pozor na to, SSL/TLS je protokol založený na asymetrickém šifrování (např. AES), specifikuje handshake a podobné věci. SSH (a spousta dalších aplikací) používá AES bez SSL/TLS (a tudíž teoreticky zranitelné nejsou, pokud "chyba" byla objevena v SSL/TLS, resp. třeba v tom handshake), ale třeba takový OpenVPN k nim nepatří, proto jsem ho zmínil.
-
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í.
-
j (neregistrovaný)
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.
-
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:
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?
-
t3 (neregistrovaný)
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 :)
-
Ivan (neregistrovaný)
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.
-
NN (neregistrovaný)
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)...
-
j (neregistrovaný)
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.
-
MilanK (neregistrovaný)
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 -
Storm (neregistrovaný)
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. -
Program (neregistrovaný)
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.
-
Q (neregistrovaný)
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/ -
Program (neregistrovaný)
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.
-
Q (neregistrovaný)
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
-
omg (neregistrovaný)
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.
-
MilanK (neregistrovaný)
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.
-
MilanK (neregistrovaný)
Ú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í.
-
MilanK (neregistrovaný)
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.
-
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).
ČLÁNKY DO MAILU