Rég volt szó minden online tranzakciók védőszentjéről, a TLS-ről, pedig történt pár dolog az elmúlt hónapokban - ezer bocs, mostanában viszonylag kevés időm/energiám van kriptó pépöröket értelmezni.

Mindenek előtt egy kis múltidézés: Kb. másfél éve jött ki Rizzo-Duong páros a BEAST támadással, ami lényegében egy padding oracle stílusú (CBC módban működő blokktitkosítókat érintő), választott nyílt szöveg alapú támadás. Egy évvel később a duó bemutatta a CRIME-ot, ami a kommunikáció optimalizálására használt tömörítés tulajdonságait alapul véve következtetett a nyílt szöveg részeire, szintén blokktitkosítók esetében. 

Aztán jött a Lucky 13, ami a BEAST-hez hasonlóan padding oracle-t használ, de ezúttal egy idő-alapú side-chanellen figyeli meg, hogy egy adott padding az adott üzenethez helyes-e. 

A három probléma eddig egy csapásra megoldható volt az RC4 folyamtitkosító használatával (amire több nagy szolgáltató az eredmények hatására át is állt), melyről ugyan eddig már sok rosszatt hallottunk pl. a WEP kapcsán, de úgy tűnt, hogy a TLS-hez még jól használható (de a datagram alapú, szintén érintett DTLS-hez már nem...).

A Lucky 13-t is publikáló kutatócsoport aztán kissé megkavarta a dolgokat, miután nem rég felefedezték, hogy az RC4-et használó TLS folyamokba is bele lehet hallgatni a BEAST-ével nagyjából azonos támadói modell mellett, az algoritmus által generált kulcsfolyam bizonyos részei ugyanis nagy számú üzenet esetén megjósolhatók a kriptoszöveg alapján. 

A kriptográfusok az eredmények láttán temetik az RC4-et - előrejelzésük szerint a támadás jelenlegi formájának kivitelezéséhez szükséges több tízmilliós üzenetszám jelentősen csökkenni fog -, és a blokktitkosítókra történő visszaállásra buzdítanak, hiszen kliens oldalon az Apple kivételével minden böngészőgyártó implementálta a BEAST és Lucky 13 elleni védelmi megoldásokat, a CRIME pedig a kérések tömörítésének megtiltásával hatástalanítható.

Sajnos azonban az RC4 támadással párhuzamosan a CRIME-ot is továbbfejlesztették: az új, TIME-nak keresztelt támadás a kérések helyett a válaszok tömörítését, pontosabban a tömörítés idejét figyeli, így megkerülve a CRIME-ra bevezetett védelmeket és egy gyengébb támadói modellben  valósítva meg nyílt-szöveg visszaállítást.

Jogos kérdésként merül fel, hogy akkor most mi legyen?

Mindenek előtt jegyezzük meg, hogy a fenti támadások egyike sem jelent tényleges, gyakorlati veszélyt az általános TLS forgalom számára: a titkosítás sikeres feloldásához a támadónak amellett, hogy általában man-in-the-middle pozícóba kell kerülnie, az eszközeit speciálisan a szerver-alkalmazásra kell hangolnia, miután bősz imádkozásba kezdhet az alacsony hálózati késleltetésingadozásért és hogy a felhasználó ne zárja be a böngészőt a megfelelő csomagszám kiküldése előtt - és akkor még mindig nem kezdett semmit mondjuk az esetleges kétfaktoros autentikációval. Ennél néhány nagyságrenddel egyszerűbb befertőzni a célpontot valamilyen malware-rel. 

A kutatások azt azonban egyértelműen jelzik, hogy a TLS-el komoly problémák vannak, melyekkel mihamarabb kezdeni kell valamit. Az új támadások miatt az RC4-et érdemes hanyagolni (bár ne lepődjünk meg, ha teljesítmény okok miatt nagy helyeken még találkozunk vele), a TIME-ra pedig elkerülő megoldást adhatnak a böngészőgyártók az XmlHttpRequestek implementációjának módosításával (pl. véletlen késleltetés bevezetése), így végső soron a TLS 1.0 és 1.1 CBC módú blokktitkosítóival is elkaristolhatunk még egy darabig. A TLS 1.2 támogatás az autentikált titkosító módok (pl. AES-GCM) preferálásával jelenleg jó hosszútávú megoldásnak tűnik - aki teheti, valósítsa meg ezek támogatását kliens és szerver oldalon is!