Vlákno názorů k článku Pozor na podvodné emaily od Petr - K cemu vlastne https? Vsichni se odvolavaji na...

K cemu vlastne https? Vsichni se odvolavaji na to, ze https je bezpecne, ale proc?

Lidi, kdo z vas si naposledy zkontroloval certifikat serveru, jestli je to opravdu ten spravny? Kdo z vas kdy kontroloval, zda firma XXXYYY Inc. je skutecne ten spravny provozovatel sluzby www.zzzz.com? Je moc pekne, ze mate bezpecny sifrovany kanal, takze vasi komunikaci s podvodnikem nikdo treti neodposlechne...

Doporucuji na tema SSL clanky Bruce Schneiera, je tam opravdu dost podnetu k zamysleni (i kdyz s nimi treba nebudete souhlasit)...

Abych predesel nepochopeni: https je bezpecne v tom smyslu, ze komunikace je nejspis nedesifrovatelna. Nedava vam ale dost jistoty, ze druha strana je duveryhodna. Tento clanek je pritom na tema "druha strana se za nekoho vydava"...

:-) zrejme jste necetl nejnovejsi TZ ICZ a.s.? Jinak byste o HTTPS smahem toto tvrdit nemohl... - prolomeni za 14 az 50 hodin na beznem stroji (cca 13mil kombinaci) v serializovanem modu mi neprijde tak nedesifrovatelne...

Ani kontrola certifikatu serveru nemusi byt, v pripade zasilani dat, dostatecnou metodou. Implementace SSL v prohlizecich je provedena takovym zpusobem, ze prakticky vylucuje takove nastaveni, aby byla komunikace bezpecna. Ale to uz jsem psal v samostatnem clanku davno (s bezpecnostnimi tematy je to jako s modou - spousta z nich se pravidelne vraci) ...

Skoda, ze ten Vas clanek zastaral v tom podstatnem - bezpecnost SSL/TLS...:-(

Preci jen je to clanek dva roky stary - a to uz znamena, alespon v IT, ze jde o clanek historicky. Nicmene, troufam si predpovedet, ze problem s TLS/SSL se podari odstranit na vetsine pocitacu do pul roku az do roka - ale nebezpecnost soucasnych browseru (coz bylo hlavni naplni clanku) nam tu jeste hezkych par let zustane, pokud ne navzdy ... ;-(

Akorátže to ten stroj nedělal 50 hodin nic jinýho, než odpovídal na requesty útočníka. Toho si už obvykle všimne i méně schopný admin ;-) Kromě toho, jestli jsem to pochopil správně, je tím prolomena pouze session, která tímpádem musí taky trvat tak dlouho, jinak už není co prolamovat (ale klidně mě opravte, zas tak podrobně jsem to nestudoval :-)

Myslim, ze je to horsi, teda priznavam, ze jsem ten 14 strankovy elaborat cetl, ale ne zcela detailne. V podstate se jedna o to, ze utocnik pomoci BVO (coz jsou nejaka magicka cisla s hezkou definici na zaklade urcitych zakladnich pravd, teoremu a lemm - popsano tamtez) - kterych je pro 1024bitove RSA radove milion (tusim, ze se psalo kolem 2.5). Kdyz se inicializuje 'SSL session', tak je pouzito urcite premastred magicke numero, ktere ma byt tajne a klient vygeneruje patricne response... Problem je v tom, ze pomoci 'utoku' pres BVO jste schopen v medianu 50 hodin zjistit to premastered magicke numero a z toho, z BVO a odpovedi ze serveru jste schopen v tomtez case zjistit RSA 1024bit klic. A to je podle meho ten zakladni kamen urazu. Prochazeni seznamu BVO je rychlosti zhruba 50BVO/s na 2xPIII (tusim, ze 1.4GHz). Takze si myslim, ze:

• 1. session (na ktere zkoumam BVO) nemusim krast, mohu si vytvorit vlastni
• projiti milionu BVO neni casove ani prostorove (myslim tim distribuovane pocitani, rekneme 10BVO/hodina) omezen
• v okamziku, kdy znam patricne premastered cislo a na zaklade definovanych formuli dopocitam/ziskam RSA klic je jedinnou obranou vygenerovani noveho klice na serveru. Z LOGu, kdo pouzil stary RSA klic se v podstate skoro nic nedozvim, protoze ho budou pouzivat jak vsichni 'legalni' klienti, tak utocnik

Pokud se v necem v mych zaverech mylim, prosim necht mne nekdo opravi, at nesirim zbytecne bludy, zpravu jsem precetl vcera (definice jsem veru nezkoumal, nejak mam k te Teoreticke informatice geneticky odpor uz od studia na VS:-]), vcetne casovych a slozitostnich elementu a musim rici, ze mne to vubec netesilo - toto neni utok v teoreticke rovine, dokonce se domnivam, ze je to daleko zavaznejsi nez utok pomoci postranniho kanalu - casu...

Ja jsem to, na rozdil od vas, nemel cas prostudovat uplne dukladne, nicmene - jste si jisty tou moznosti zjistit privatni klic ?

Ne mate pravdu, timto smetim se mi moje docasna pamet zaneradila zrejme odjinud nez z te technicke zpravy, nicmene cituji z abstraktu: We show that incorporating a version number check over PKCS#1 plaintext used in the SSL/TLS creates a side channel that allows the attacker to invert the RSA encryption. The attacker can then either recover the premaster-secret or sign a message on behalf of the server. Za pozornost stoji zejmena posledni cast posledni vety: nebo podepsat zpravu v zastoupeni serveru - tedy de facto to same, jako by ten privatni RSA klic mel...:-(