Raccoon Attack - támadás a TLS ellen

I am an admin, should I drop everything and fix this?

 

Probably not. Raccoon is a complex timing attack and it is very hard to exploit. It requires a lot of stars to align to decrypt a real-world TLS session. There are, however, exceptions.

Kutatók egy új támadási metódust publikáltak Raccoon Attack néven, ami lehetővé teszi a rosszindulatú támadók számára a TLS 1.2 (és korábbi) kapcsolatok dekriptálását. Mindazonáltal, sikeres támadás indítása nem könnyű feladat (értsd: jelenlegi ismeretek szerint rohadt nehéz). További infók: raccoon-attack.com

Hozzászólások

Akik tájékozottabbak azoktól kérdezném:

 * Ha jól értem az SSL-es szervereket (pl https) kellene átkonfigurálni, hogy TLS1.2-t már ne fogadjon el, csak TLS 1.3-at.

 * Mekkora része lehet a piac böngészőinek, ami nem tudja még a TLS 1.3-at?

Nem kell a TLS 1.2-t letiltani. Elég ha kikapcsolod a DHE alapú ciphereket. Persze előfrodulhat, hogy van olyan kliens ami csak DHE-vel megy,de ritkább mint ami még nem tud TLS1.3-at szvsz.

Szerk: Nem biztos, hogy elég, nem tudom az ECDHE érintett-e.

Szerk2: Azt írják a támadást részletető oldalon az ECDHE nem érintett....

Persze előfrodulhat, hogy van olyan kliens ami csak DHE-vel megy

Van olyan. Az utolsó Opera 12, az pont ilyen, a DHE-t még implementálták, TLSv1.2-t is tud, de ECDHE-t már nem.

Viszont a CloudFlare már legalább egy éve kidobott mindent, ami nem ECDHE min. TLSv1.2. Ergó már rég nem megy egy csomó weboldal Opera 12 alól.

Hát ha ez működik, akkor ne felejtsél el szólni :D

A squides megoldáson gondolkodtam, de aztán több energiát igényelne, mint amennyit bele akarnék rakni. Sajnos nem csak az SSL az egyetlen problémás dolog, már vagy 3-4 évvel ezelőtt eljutott oda valamelyik népszerűbb JS library, hogy az Opera JS engine-jét kiakasztja. Nagyon sok weboldal egy-egy frissítés után használhatatlan lett, mert csak teker a JS...

Feltétlen, ha egyszer rászánom magam.

Letiltod a JS-t és ha a szöveg olvasható, nyertél. Ha nem, mert mondjuk kliensoldali rendering van, akkor cumi. Olyankor én kinyitom PaleMoon-ban. Vagy, ha abban sem működik, akkor IceWeasel-UXP-ben. Ha abban sem, akkor elgondolkodok rajta, hogy kell-e ez a weboldal nekem. Ha muszáj, akkor Chromium.

Off: Aki kitalálta a kliensoldali renderinget, azt gépközelbe se lett volna szabad engedni. Nem ám kész HTML kódot töltünk le és rábízzuk a natív browsermotorra, hogy hogyan állítja össze a fát vagy illeszti be az új kódot a fába AJAX esetén, hanem átadunk valami elbaszott adatszerkezetet és abból csináljuk ezt meg kézzel. Egy interpretált scriptnyelvből. (Igen, tudom, van JIT is (már ahol), úgy is sokkal lassabb, mint a natív...) Holott a szerveroldalnak kb. mindegy, hogy a struktúráltan átadandó adatokat HTML-ként, vagy JSON-ként, vagy akármi másként adja át; mondanám, hogy a HTML pár százalékkal - azaz kb. párszáz Byte-tal - több nyelvi sallanggal jár mondjuk a JSON-hoz képest, viszont nem kell hozzá N darab sokmegás erőforrászabáló JS keretrendszer és nem terheljük rommá folyamatosan az összes klienst...

viszont nem kell hozzá N darab sokmegás erőforrászabáló JS keretrendszer és nem terheljük rommá folyamatosan az összes klienst...

Tehát a gond nem a strukturált adatból "vastag" kliens állít elő UI-t elvvel van, hanem a "sokmegás erőforrászabáló JS keretrendszer" (ill. sok esetben az azokat rosszul használó alkalmazásokkal), nem?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

A probléma azzal van, hogy ahelyett, hogy a szerver kész HTML-t pumpálna ki, amit a browser egy-az-egyben fel tudna használni, ahelyett inkább a kliensoldalon építik fel node-onként ugyanazt a HTML-t, sokkal több erőforrásért. A végeredmény így is HTML lett, de nem egyszer szereltük össze szerveroldalon, hanem sokszor a kliensoldalon. Az csak a hab a tortán, hogy ez JS-ben van, de igazából bármiféle nyelvet használnának a browserek, mindenképpen lassabb és erőforrásigényesebb lesz az ilyen custom render a natív helyett, hiszen a gépi kódú nodebuilder helyett egy interpretált fut: ehelyett: adat a szerveren -> HTML kód -> browser -> webpage, ez van: adat a szerveren -> JSON (vagy amit akartok) -> browser -> kliensoldali nem natív renderer -> webpage.

1. A "desktopszerű dinamikus működés" csak egyes részeit érinti a weblapoknak; miért kell az egészet így csinálni?
2. A "desktopszerű dinamikus működés" nem feltétlenül igényli, hogy a különféle részeket node-onként hozd létre és fűzd össze interpreterből; egyidős a JS-sel az innerHTML property, ha felül akarok írni valamit és kb. a bronzkor óta létezik az insertAdjacentHTML() függvény a beszúrkálásokhoz, hozzáfűzésekhez. A direkt node-os cseszegetésre kb. akkor van szükség, amikor helyben állítasz valamilyen node szerkezetet össze, amin egy raklap egyéb attribútumot is be kell állítani, viszont maga a szerkezet totál egyszerű, pl. input-ok hozzáfűzése egy listához, vagy whatever.
3. A "desktopszerű dinamikus működés" megvalósításához pár sor JS is elég, mi a túrónak hozzá hatvannyolcezer féle JS keretrendszer. 4 teh lulz?

A végeredmény így is HTML lett, de nem egyszer szereltük össze szerveroldalon, hanem sokszor a kliensoldalon. 

A HTMLt mindenképp ugyanannyiszor rakod össze függetlenül attól, hogy kliens oldal-on van a HTML "generálva", vagy szerver oldalon. (A renderelést a böngésző végzi a HTML-ből, azt ne keverjük ide, az mindenképp ugyanúgy történik bármelyik oldalon is áll elő maga a HTML.) Persze előfordulhat olyan eset, hogy a HTML-t cache-elni lehet, és akkor elég a cacheből visszaadni, de a mai weboldalak töredéke lehet ilyen, többnyire teljesen egyedi oldal jelenik meg minden letöltéskor. 

Másrészt egyáltalán nem egyértelmű, hogy nem hatékonyabb ha a kliens oldalon építed a HTML-t, ugyanis így tényleg csak annyi adatmozgás történik a kliens és a szerver között, ami feltétlenül szükséges, míg a hagyományos JS nélküli HTML esetében minden egyes kattintásra a teljes oldalt újra kell tölteni függetlenül attól, hogy épp mekkora része változatlan az oldalnak. A felhasználói élményről nem is beszélve. Persze ez minden oldalnál egyedi, hogy épp melyik éri meg jobban, mondjuk egy híroldalnál jól tud működni a hagyományos HTML, de minél inkább elmozdulunk webalkalmazás irányba ez annál kevésbé lesz így. És azt akkor meg sem említettem, hogy gyakorlatilag ma már nem létezik olyan oldal, amiben ne lenne valamennyi JS.

 ehelyett: adat a szerveren -> HTML kód -> browser -> webpage, ez van: adat a szerveren -> JSON (vagy amit akartok) -> browser -> kliensoldali nem natív renderer -> webpage.

Azért ez így elég félrevezető, úgy érzem pár réteget minta lehagytál volna, de a valóság azért jóval bonyolutabb:

Első eset:

DB -> server / repository layer (-> server / service layer - egyszerűbb esetben ez kimaradhat)-> server / controller layer-> server / html generálás -> browser / HTML megjelenítés

második eset:

DB -> server / repository layer (-> server / service layer - egyszerűbb esetben ez kimaradhat) -> server / controller layer -> browser / html generálás JS-ből -> browser / HTML megjelenítés

És a meglepetés az, hogy igazából mindkét esetben ugyanannyi lépés / réteg van, gyakorlatilag tényleg csak annyi a különbség, hogy melyik oldalon áll elő a controllerből kijövő adatből a HTML. Persze nem mondom, hogy minden websitenak ilyen a felépítése (de azért az esetek túlnyomó többsége ilyen, az elmúlt 10+ évben gyakorlatilag ez az architektúra egyeduralkodó volt), de ahol nincsennek ilyen szépen meg a rétegek, ott is tipikusan ezek a lépések történnek.

Annak pedig a fejlesztési oldalon nagyon nagy előnyei vannak (fejlesztésnél, tesztelésnél és deploymentnél is), ha a kliens és a szerver oldal architekturálisan is el tud különülni ez az egyik fő oka annak, hogy mára ez az irány dominál.

A HTMLt mindenképp ugyanannyiszor rakod össze függetlenül attól, hogy kliens oldal-on van a HTML "generálva", vagy szerver oldalon. (A renderelést a böngésző végzi a HTML-ből, azt ne keverjük ide, az mindenképp ugyanúgy történik bármelyik oldalon is áll elő maga a HTML.) Persze előfordulhat olyan eset, hogy a HTML-t cache-elni lehet, és akkor elég a cacheből visszaadni, de a mai weboldalak töredéke lehet ilyen, többnyire teljesen egyedi oldal jelenik meg minden letöltéskor.

Ezt szépen meg is válaszoltad magadnak: cache. Hogy nem mindenütt használják, az egy dolog, de a lehetőség megvan rá.

Másrészt egyáltalán nem egyértelmű, hogy nem hatékonyabb ha a kliens oldalon építed a HTML-t, ugyanis így tényleg csak annyi adatmozgás történik a kliens és a szerver között, ami feltétlenül szükséges, míg a hagyományos JS nélküli HTML esetében minden egyes kattintásra a teljes oldalt újra kell tölteni függetlenül attól, hogy épp mekkora része változatlan az oldalnak.

Ez hatalmas tévedés. Olvasd el még egyszer, amit mondtam; kulcsszavak: AJAX, innerHTML, insertAdjacentHTML().

A felhasználói élményről nem is beszélve.

Éppen a felhasználói élmény az, amit a lassúság és az erőforrászabálás kinyír.

Persze ez minden oldalnál egyedi, hogy épp melyik éri meg jobban, mondjuk egy híroldalnál jól tud működni a hagyományos HTML, de minél inkább elmozdulunk webalkalmazás irányba ez annál kevésbé lesz így.

Ld. a kettővel előbbi bekezdést. Én asszem, hogy te valamit nagyon félreértettél, én nem a dinamikusan betöltött tartalomról beszéltem, hanem a JS-ből történő nodetree-buildingről.

És azt akkor meg sem említettem, hogy gyakorlatilag ma már nem létezik olyan oldal, amiben ne lenne valamennyi JS.

Ööö...és?

Azért ez így elég félrevezető, úgy érzem pár réteget minta lehagytál volna, de a valóság azért jóval bonyolutabb:

A levezetés céljából irreleváns vagy nem létező réteget. Kit érdekel, hogy honnan jön az adat? Egyáltalán, miért kéne feltétlenül DB-ből jönnie? Nem ez volt a lényeg. Hovatovább, te viszont kihagytál egy lépést a második esetből, nevezetesen az adatszerkezet összeállítását. A JSON-t talán nem kell összeállítani, mint a HTML-t? A te második eseted így kéne, hogy kinézzen:

DB -> server / repository layer (-> server / service layer - egyszerűbb esetben ez kimaradhat) -> server / controller layer -> server / json (vagy egyéb struktúra) generálás -> browser / html generálás JS-ből -> browser / HTML megjelenítés

Így aztán ugyanott tartunk, mint az én leegyszerűsített sémámnál: a kettes esetben a szerveroldalon így is van struktúragenerálás, a kliensoldalon meg manuális nodetree-building és így is egyel több lépés a kettes eset.

És a meglepetés az, hogy igazából mindkét esetben ugyanannyi lépés / réteg van, gyakorlatilag tényleg csak annyi a különbség, hogy melyik oldalon áll elő a controllerből kijövő adatből a HTML. Persze nem mondom, hogy minden websitenak ilyen a felépítése (de azért az esetek túlnyomó többsége ilyen, az elmúlt 10+ évben gyakorlatilag ez az architektúra egyeduralkodó volt), de ahol nincsennek ilyen szépen meg a rétegek, ott is tipikusan ezek a lépések történnek.

Kivéve, hogy nem ugyanannyi réteg a két megoldás, mert a kettesből kifelejtettél egy fontos réteget; ld. egyel feljebb. A te sémádnál a szerveroldali "kontroller" és a browser között egy nagy semmi volt, mintha az adat varázslatosan csak átkerült volna az egyikből a másikba. Az adatszerkezet összeállítását a szerveroldalon nem lehet megspórolni. Cachelni persze a kapott JSON-t is lehet, ahogy a HTML-t is, de ettől még a túloldalon marad a manuális nodetree-building, a lépések száma nem változik.

Annak pedig a fejlesztési oldalon nagyon nagy előnyei vannak (fejlesztésnél, tesztelésnél és deploymentnél is), ha a kliens és a szerver oldal architekturálisan is el tud különülni ez az egyik fő oka annak, hogy mára ez az irány dominál.

A szerver és a kliens "architektúrálisan" mindenképpen elkülönül, semmi szükség erre a pocsékoló felállásra. Egyáltalán nem ez az oka, hogy ez az irány dominál. Azért dominál ez az irány, mert ez a trend. A divat.

asszem nem a böngésző lesz ezesetben a szűk kerszetmetszet :D

 

Sok enterspájz még épp azon igyekszik, hogy a TLS 1.2-re átálljon ;)

És ilyen környezetekben nem csak böngésző megy TLS-en, hanem kismillió egyedi tákolmány, ami ráadásul 'mission critical' <- pont az ilyenek miatt nem lehet évekig előrelépni security területen.

Szerkesztve: 2020. 09. 11., p - 07:45

Figyelem.

c