[Heavy OT]: ADSL modem

[Petr Stetina]

Naprosto s vami souhlasim, ale moznost podstrcit napadenemu cerva, ktery 
primo z jeho stroje provede potrebne operace se mi jevi jako nejjednodussi.

BTW: kde pracujete? ;)

Petr

Thomas Shaddack wrote:

> On Tue, 22 Jun 2004, Thomas Shaddack wrote:
> 
> 
>>V zasade jsou dve moznosti.
>>
>>Aktivni utok. Hijacknout SSL spojeni a pouzit man-in-the-middle. Vyvola to
>>hlasku o neplatnosti certifikatu, ale user pres to nejspis proklikne bez
>>dalsich dotazu. Nektere unpatchle MSIE navic maji bug co umoznuje triky s
>>podepisovanim certifikatu co tohle zakryji. Dalsi postup je najit nejakou
>>certifikacni autoritu ze seznamu toho co je v browseru jako default, a
>>nakecat jim ze jsi dotycna banka, a dostanes certifikat. Spouste mensich
>>firmicek staci par dolaru za poplatek a hlavickovy papir se zadosti.
> 
> 
> Existuje jeste treti moznost, kombinace utoku hrubou silou a MITM, kdy se
> nam oznameni o podezrelem certifikatu nezobrazi.
> 
> Presmerujeme na sebe spojeni s cilovym serverem; napr. zaridime, aby se
> www.banka.cz z cilove masiny misto toho resolvovalo na IP adresu
> odpovidajici padouch.cz, a pak spojeni odposlouchavame a za behu
> modifikujeme. Faze, kde se server s klientem dohaduji na dalsim postupu,
> je jeste nezabezpecena; v pozadavku klienta nebo nabidce serveru muzeme
> prohlasit, ze dotycny podporuje jenom SSLv2 a/nebo jenom 40-bit sifru.
> Pokud jsou klient i server nakonfigurovani tak, ze je to pro ne
> prijatelne, bude vysledne spojeni slabe a bud napadnutelne hrubou silou
> pres rozlousknuti 40-bit klice, coz je 3.0948501.10^26 krat jednodussi nez
> utok na 128 bitu a v dnesni dobe docela dobre realizovatelne, nebo pres
> znamou zranitelnost v SSLv2 protokolu (dnes se pouzivaji SSLv3 a jeho
> naslednik TLSv1, ale SSLv2 je jeste porad podporovano ve vetsine aplikaci,
> pokud neni vyrazeno v konfiguraci, coz osobne doporucuji).
> 
> Proti tomu ale existuje snadna obrana. Pokud je na kterekoliv strane
> (klient nebo server) zakazano pouziti SSLv2 a oslabenych exportnich
> "sifer", protivnik neuspeje a pokus o spojeni selze.
> 
> Zde je mozno poukazat na dalsi z mnoha nevyhod Microsoftu. Jejich
> implementace HTTPS (coz je HTTP obalene do SSL) mi pri spojeni s HTTPS
> serverem tvrdosijne trva na pouziti sifry RC4-MD5, coz mozna nemusi byt
> dostatecne robustni. (Jenomze, jak by se nam dostalo reakce z Redmondu,
> 640 kB RAM a 128 bitu klice musi stacit kazdemu.) Naproti tomu napr.
> Mozilla rutinne pouziva Diffie-Hellmanovy efemerni klice, AES256, a SHA,
> coz je proti nepouziti efemerniho klice, 128 bitu starsiho algoritmu misto
> 256 bitu novejsiho, a 160 nebo 256 bitu dlouheho hashe misto 128 bitu
> dlouheho (ono se sice 128 bitu muze zdat hodne, ale podle Schneiera je pry
> mozne zautocit na hash pomoci kolizi, coz se zacina projevovat uz od
> poloviny bitove delky, takze 128 bit hash ma proti kolizim odolnost jenom
> na urovni 64 bitu, coz je na dnesni dobu uz dost malo, a jistota je
> jistota; kdovi co Baby Gross dostal od svych pratel z FBI za hracky).
> Zapomnel jsem vysvetlit proc je DH dulezity algoritmus pro SSL cipher
> suites; pro symetrickou sifru v ramci spojeni se bez nej pouziva klic
> zasifrovany private klicem serveru, takze pokud ma protivnik
> odposlechnutou komunikaci a pak si prijde pro kopii privatniho klice, je
> schopen komunikaci rozlustit; pri pouziti cipher suit s podporou
> Diffie-Hellmanova algoritmu se klic dohaduje pomoci DH handshake, a
> soukromy klic slouzi jenom k jeho podepsani. Protivnik pak muze mit
> vsechny pakety z komunikace, a pozdeji ziskany soukromy klic mu nijak
> nepomuze v jejich dekodovani. DHE-RSA-AES256-SHA je podstatne lepsi
> moznost nez RC4-MD5.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> HW-list@mailman.nethouse.cz
> http://nethouse.cz/mailman/listinfo/hw-list