Sajnos úgy érzem, nem lehet tovább halogatni, hogy a Julian Rizzo és Thai Duong által helyi idő szerint pénteken, az argentín Ekoparty konferencián prezentált SSL/TLS támadásról írjak, annak ellenére, hogy még mindig nem tudni pontosan, mit is hozott össze a két kutató.
Minden esetre már megjelent néhány igen hasznosnak tűnő összefoglaló, melyek nagy vonalatkban körüljárják a támadás főbb jellegzetességeit. Az első és legfontosabb, hogy Rizzo és Duong egy majd' tíz éve ismert, választott nyílt szöveg alapú támadásra mutatott egy proof-of-concept megvalósítást - ez lett a BEAST. Az eredeti probléma gyökere az, hogy a TLS 1.0-t használó böngészők CBC módban az utolsó üzenet utolsó blokkját használják a következő üzenet IV-jeként, vagyis a különböző HTTP kéréseket egy hosszú plaintext üzenetté fűzték össze. Nem CBC-módban használt blokktitkosító, illetve a folyamtitkosító használatát kikényszerítve elkerülhetjük a támadást.
A támadás lényege az, hogy egy támadó képes ellenőrizni, hogy egy adott titkosított blokk nyílt szövege megegyezik-e egy általa megtippelt értékkel: Tegyük fel, hogy a támadó tudja, hogy Alice jelszava utazik az M_i blokkban (ezt a támadó titkosítva, C_i-ként látja)! A támadó nem tudja megfejteni ezt a blokkot, viszont meg tudja jósolni az következő IV-t (ez legyen X), valamint rá tudja kényszeríteni Alice-t, hogy küldje el az
X + C_(i-1) + P
üzenetet, ahol P a támadó által megsejtett jelszó, a + a bitenkénti XOR-t jelöli, C_(i-1) pedig a M_i üzenet előtt küldött kriptoszöveg. Amikor a rejtjelező XOR-olja ezt az üzenetet a következő IV-vel, az X kiesik. Amennyiben pedig P=M_i (vagyis a támadó helyesen tippelt), a titkosítás után C_i kell legyen az eredmény.
Ez a támadás jól láthatóan viszonylag erős támadói modellt feltételez. Rizzo és Duong érdeme abban áll, hogy praktikus támadási szcenáriót sikerült mutatniuk, mégpedig az egyik legelterjedtebb felhasználási módra, a webböngészésre.
A támadshoz olyan technológáik használhatók, amelyek megengedik tetszőleges bináris adat átvitelét, úgy mint a Java, vagy a HTML5 WebSockets. Utóbbi esetben a HTTP kliens és szerver előzetesen meg kell, hogy egyezzen a WebSocket használatban, a kézfogás során pedig átvitelre kerülhet a kliens sütije is. Ha feltételezzük, hogy már a kézfogás egy részét is irányítani tudja a támadó (pl. a szerveren belüli útvonal megadásával), elérhető, hogy az egyik üzenetblokk végén csak a süti első bájtja szerepeljen. A blokk maradék része ekkor egyszerűen jósolható (sima HTTP fejlécekről beszélünk), ezért a támadó a fenti módszerrel néhány száz kérésből képes kitalálni a bájtot. A következő lépésben egyel csökkentve a konrollált üzenetrész méretét a süti következő bájtja következhet, és így tovább.
Hogy mindennek milyen hatása lesz a mindennapi életünkre? Várhatóan nem sok. A támadás eleve egy közbeékelődéses szituációt feltételez, ekkor pedig jóval hatékonyabb módszernek tűnik belőni egy SSLStripet. A böngészőgyártók már tesztelik azokat a foltokat, melyek segítségével a kompatibilitást megtartva kiküszöbölhetőek az ilyen jellegű protokolltámadások, és a Tor felhasználók is megnyugodhatnak. A bejelentéstől függetlenül egyébként a WebSocket specifikációt időközben úgy módosították, hogy az újabb implementációk már jóval nehezebben használhatók fel ilyen kriptós trükkökre.
Abból a szempontból viszont a kutatás mindenképpen hasznos lesz, hogy végre talán megadja azt a rég óta várt lökést a különböző SSL/TLS könyvtárak gyártóinak és felhasználóinak, hogy végre teljes támogatást adjanak a TLS 1.1-es és 1.2-es, megerősített változataihoz. És akkor jövőre valaki majd megint készíthet egy ütős prezit a downgrade támadásokról :)
Frissítés: A cikk és a referencia implementáció letölthető innen (link frissítve).
