Vlákno názorů k článku SSL v ohrožení: komunikaci je možné dešifrovat od Jiří J. - cituji: "Jakmile dojde na spojení se zajímavým serverem, útočník...
-
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.
ČLÁNKY DO MAILU