Nos dióhéjban nézzük, miről is beszél Moxie Marlinspike:
Tanúsítvány láncolás
A PKI rendszerek bizonyos szint fölött definíció szerint a bizalmon alapulnak. Bár egy weboldal tanústványát kiállító entitásról általában egy másik hitelesítő intézmény kezeskedik, a lánc végén mindig ott a "Root CA" (gyökér hitelesítő hatóság), akiben kénytelenek vagyunk (technológiai értelemben) vakon megbízni.
Moxie mondja: csinálj egy köztes CA-t, és adj ki vele tanúsítványokat minden féle zsiványnak! A gézengúz tanúsító tanusítványai azonban visszavonhatók. Károk persze keletkeznek, de a világ nem dől össze.
Kesze-kusza böngészők
Egy átlag felhasználó számára nem azonnal szembeötlő, hogy mikor jár hitelesített oldalon, a sok hamis riasztás pedig rossz reflexeket nevel az emberekbe (Igen, Akarom, Tényleg, Biztosan mantra...). Itt tényleg van merre előrelépni, de megint nincs szó a rendszer alapjainak döntögetéséről, ez egyszerű interfészfejlesztés. Ráadásul a jobb bankok kiterjesztett érvényességű tanúsítványai még mindig elég hivalkodóak szerencsére.
Senki nem írja le az s-t
Mármint a http végére. Mert hogy még http://-vel is csak viszonylag kevesen kezdik az URL-jeik beírását. Így a forgalom először nem biztonságos csatornán indul el, ebbe pedig be lehet avatkozni, és még mielőtt az áldozat békés vizekre jutna, be lehet rántani az örvénybe. Persze a marhákat is igyekeznek megnyugtatni, mielőtt a vágóhídra küldik őket: az elcsent adatfolyamba beteszünk pár képet lakatokról, és mindenki a legnagyobb nyugalommal kürtöli szét az adatait a hálózatba.
De itt sem a HTTPS kapcsolatba ékelődtünk be, hanem a köztudottan védtelen HTTP-be.
Szeretünk Unicode
Erről már volt szó. Moxie most azzal egészítette ki a dolgot, hogy mi van akkor, ha tetszőleges domain alá olyan aldomaint regisztrálunk, ami látszólag megegyezik a biztonságosnak hitt oldal megszokott URI-jával. Konkrétabban: pl. ha az aldomain a / és ? karakterekhez megtévesztésig hasonló Unicode karaktereket tartalmaz, elhitethejük, hogy a látogató jó helyen jár, miközben csak az aldomain hosszú-hosszú nevét látja, a valódi hoszt pedig elveszik a látszólagos paraméterek között, vagy már ki is lóg a címsor látható részéből.
Ez persze jó eleme lehet egy támadásnak, de az SSL-hez megint semmi köze.
Nagyjából ezek voltak az előadás fő pontjai. Ezek a támadások tényleg igen veszélyesek lehetnek az átlag felhasználók számára. és minden bizonnyal a rengeteg megszerzett belépési adatról sem füllentett a srác. De a problémák kezelésének nem tesz jót, ha az amúgy sem túl jó marketinggel rendelkező, de még mindig az e-kereskedelem masszív bástyájának tekinthető SSL-ről elkezdünk hülyeségeket beszélni.
Frissítés:
A "kísérletben használt" sslstrip program letölthető innen.
M@rine 2009.02.20. 12:10:41
Ujdonsag nem kerult napvilagra, ez a fishing jellegu tamadas eddig is ismert elemekbol lett osszevaogatva...
Kockazat kezelere tippek:
- mindig meg kell nezni hogy mihez kapcsolodunk: https? url stimmel (teljes, nem csak ami latszik)?
- levelben jott linkeket NE nyissunk meg, meg akkor se ha ismert oldal neveben kuldik. (felado ugye tetszolegesen hamisithato)
- ha https oldalra akarunk menni, irjuk be kezzel, vagy bookmark. utobbi ellen lehet erv hogy a bongeszok idokozonkent serulkenyek lehetnek bookmark atirasra. noha kicsi a valoszinusege hogy pont a mi kedvenc bakunkat hamisitjak.... paranoidok tegyek el txt fileba a https linkeket - elkerulendo az elgepeles.
Egyebkent a masik root ca altal kiadott tanusitvanyok ellen jo lenne ha lehetne a browserral megjegyeztetni a mar latott tanusitvanyokat. Igy ha egyszercsak masik CA irja ala akkor tudna jelezni.
Erre esetleg van valami lehetoseg? En nem tudok ilyenrol.
Udv, Marine
r@ek (törölt) 2009.02.20. 13:00:41
r@ek (törölt) 2009.02.20. 14:46:32
|Z| 2009.02.21. 16:32:23
browser.identity.ssl_domain_display kulcs értéke 1
LocationBar - kiemeli a domain-t
SSL Blacklist - A gagyi tanusítványok ellen véd
Cipherfox - megmutatja az aktuális SSL rejtjelezést
Flagfox - ellenőrzi, hogy a domain és az IP cím tényleg azonos országban vannak-e
mindennapi böngészésben segítenek, lusta vagyok megnézni minden alkalommal a tanusítvány ujjlenyomatát...
kutyacica 2009.02.21. 18:30:01
Nem kevésbé bosszantó a belépési rendszer (a login oldal ahonnan elposztolod buttonnal a jelszavad még http) - ami h h nem ebben az előadásban is felbukkan. És ez egy bank.
Amúgy élmény velük levelezni, az ugyanis a policy h kizárólag a webes felületen belülről elküldött secure mailen keresztül hajlandókat ilyen témáról írni-olvasni (ennyi volt praktikusan a válasz az első érdeklődő mailemre). Nem tudom lehet-e érezni az ellentmondást ebben :)
sebcsaba 2009.02.21. 19:20:06
A megtévesztő címek ellen meg jól tud jönni a Chrome domainnév-kiemelése.
synapse · http://www.synsecblog.com 2009.02.22. 15:05:32
Es mennnyire kurvara igazad van!!!
synapse
Hunger 2009.02.22. 16:45:42
Szóval szerintem van pár Tor user, aki szintén nagyban döngeti a mellét, hogy ő ezt tutira észrevenné, aztán közben meg már Moxie-nál vannak az adatai. ;)
r@ek (törölt) 2009.02.22. 23:48:30
czarism.com/tor-vs-security-sniffing-exit-nodes
GET SOME!!
www.youtube.com/watch?v=S06nIz4scvI
p.s.: A videoban lathato tevekenyseget maximalisan elitelem, csak szemlelteto eszkozkent szerettem volna hasznalni, hogy kb ennyi egy exit node-on jelszavakat halaszni..
Hunger 2009.02.23. 22:06:28
Nem kell itt nagyon feltűnő jelenségre gondolni és nincs szükség legtöbbször mindenféle unicode trükközésre sem. A post data url-t elég átírni egy saját url-re (ahogy Moxie is írta, remekül nem látszik se a böngészők status sorában se máshol, hogy hova lesz elküldve az adat, max. a forrásból lehetne kibányászni a címet), aztán a beérkező adatokat loggolni és utána akár továbbítani is lehet a valódi https oldalra az egészet, onnantól akár kommunikálhat titkosítottan is a szerver meg a kliens, kit érdekel, megvan a user/pass... 100-ból 100 felhasználó ebből nem vesz észre semmit, az tuti.
Hunger 2009.02.24. 00:51:12