SSLTLS - a helyzet állapota Dipl-Inform
Információk az informatikai biztonságról
SSL/TLS - a legkorszerűbb
Mi a jelenlegi helyzet az SSL/TLS biztonságával? A témáról szóló utolsó cikk óta eltelt egy ideje, és van néhány új fejlemény.
Az RC4 algoritmus problémává válik
A legutóbbi támadást 2013 március elején tették közzé: Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering és Jacob Schuldt bebizonyította, hogy a titkosításhoz használt RC4 algoritmus részben megtörhető, így a sima szöveg részei azonosíthatók. A támadáshoz CVE ID CVE-2013-2566 került be.
Pontosabban, a támadás jelenleg felhasználható a sima szövegfolyam első 256 bájtjának megtámadására. Mivel az első 36 bájt kiszámíthatatlan üzenetből áll a leggyakrabban használt SHA-1 hash algoritmusból, ezeket nem lehet meghatározni. Tehát 220 bájt titkosított szöveget lehet hatékonyan visszafejteni. Kb. 2 30 munkamenet szükséges ehhez; kb. 2 24 munkamenetnél bizonyos bájtok már megbízhatóan visszafejthetők.
Ez soknak hangzik, és az is. Legalábbis pillanatnyilag nem valószínű egy ilyen támadás, főleg, hogy előbb ki kell igazítani, hogy a támadó számára érdekes adatokat szolgáltasson. Például egy webhelybe beillesztett JavaScript-kód ismételten meghívhatja ugyanazt a HTTPS URL-t, és felhasználhatja a munkamenet sütijének visszafejtésére. De ezek csak elméleti megfontolások, gyakorlati megvalósítás még nem történt meg.
Ellenintézkedések
Az RC4 adatfolyam-kódolót a közelmúltban nagyon gyakran használták a TLS számára. Elsősorban azért, mert gyorsan kiszámítható, és (már nem) biztonságos alternatívája az SSL/TLS CBC módjának, amelyet a BEAST és a Lucky13 támadások veszélyeztetnek (erről többet egy pillanat alatt). Időközben azonban a CBC mód biztosított a BEAST és a Lucky13 ellen, így ez most az RC4 alternatívájaként szolgálhat. Ha a TLS 1.0 vagy 1.1 megfelelően javított megvalósítását használja, akkor a titkosításhoz az RC4 helyett CBC módot használhat.
Egy másik alternatíva az AEAD algoritmus, amelyet a TLS 1.2-vel vezettek be. Az RC4 elleni támadás a TLS 1.2 elterjedéséhez vezethet. Hosszú távon ez a legjobb megoldás.
Elméletileg a TLS megváltoztathatja az RC4 használatát, például elvetve az RC4 kulcsfolyam kezdetét. A gyakorlatban azonban ez a megközelítés haszontalan, mivel csak a jelenleg végrehajtott támadástól véd, de nem a lehetséges új és további fejlemények ellen. Arról nem is beszélve, hogy a TLS protokollon belül nem lehet ilyen lemondást tárgyalni, így a klienseken és szervereken a TLS megvalósításának átfogó módosítására lenne szükség.
Ugyanez vonatkozik a böngésző olyan változásaira is, amelyek a támadást kevésbé eredményessé tehetik.
TLS és a Lucky 13
Nadhem AlFardan és Kenny Paterson 2013. február elején közzétették a TLS és a DTLS (Datagram Transport Layer Security) CBC titkosítását, "Lucky Thirteen" néven. A támadás CVE-azonosítót kapott: CVE-2013-0169.
A támadás kihasználja a TLS specifikáció hibáját, és sikeresen tesztelték az OpenSSL és a GnuTLS ellen. Az OpenSSL esetében a teljes sima szöveg meghatározható, ha a GnuTLS-t legalább annak egyes részeivel használjuk (pontosabban: az egyes sima szövegblokkok utolsó bájtjának 4 bitje).
Nadhem AlFardan és Kenny Paterson kihasználják azt a tényt, hogy az Üzenet-hitelesítési kód (MAC) kiszámítása, amellyel a sima szöveget védik az észrevétlen manipuláció ellen, különböző hosszúságúak bizonyos üzenethosszak esetén. Ez lehetővé teszi a legalább két helyes kitöltési bájttal rendelkező üzenetek megkülönböztetését (amelyekkel a blokk megfelelő hosszúságúra van kitöltve) és egy helyes bájttal rendelkező vagy helytelenül formázott üzenetet.
A támadások több munkamenetből álló támadások, ezért a kívánt sima szöveget többször is el kell küldeni a sima szövegfolyam ugyanazon pontján, több TLS munkamenetben. A támadó által generált rejtjeles szöveg manipulálásával a hibaüzenetek provokálódnak, és a különböző manipulációk közötti kicsi időbeli különbségek felhasználhatók az egyszerű szöveg statisztikai megállapítására.
A legegyszerűbb esetben, ha LAN-on tesztelünk, a TLS-titkosított sima szöveg teljes blokkját körülbelül 2 32 TLS munkamenet után lehet meghatározni. ha a HMAC-SHA1-et használták MAC algoritmusként (a támadás bonyolultsága az alkalmazott MAC algoritmustól függ). Ha ismert, hogy a sima szöveg Base64 kódolású, akkor elegendő 2 19 munkamenet, ha a blokk utolsó két pozíciójának egyikében a sima szöveg egy bájtja már ismert, akkor akár 2 13 munkamenet is elegendő.
Még mindig túl sok a gyakorlati támadás a TLS ellen, főleg az interneten, és az időbeli eltérések nagyon kicsiek. A manipulált weboldalakon keresztüli támadások azonban itt is elképzelhetők. A DTLS azonban már megtámadható, mivel a munkamenet nem zárul le azonnal az első hibával.
A támadást "Lucky 13" -nak hívták, mert a MAC kiszámításakor 13 fejléc-byte-ot használnak, amelyek nélkül a támadás nem lehetséges. Bár a 13 valójában szerencsétlen szám, legalábbis a támadó számára ez itt egy szerencsés szám.
Ellenintézkedések
Elméletileg a véletlen késések megnehezíthetik a támadások időzítését, de ez a gyakorlatban nem működik, mivel ezek a véletlen késések statisztikailag is rögzíthetők; csak a támadáshoz szükséges munkamenetek száma növekedne.
A CBC titkosítás alternatívájaként az RC4 kínálta magát. Bot, mert amikor a Lucky 13-at elengedték, az RC4 elleni támadás még nem volt ismert. Időközben jobb elkerülni az RC4-et, így kizárható ez az alternatíva.
Csakúgy, mint az RC4 esetében, lehetőség van váltani az egyik AEAD algoritmusra, például az AES-GCM-re.
Végül, de nem utolsósorban a TLS CBC megvalósítása úgy alakítható, hogy az oldalsó csatorna támadásainak időzítése már ne legyen lehetséges.
A legtöbb TLS megvalósításban, mint például az OpenSSL, NSS, GnuTLS, yaSSL és PolarSSL, a Lucky 13 támadással szembeni ellenintézkedések már megvalósultak.
BŰNÖZÉS - A BEAST utódja
A BEAST fejlesztői, Juliano Rizzo és Thai Duong új támadást mutattak be az SSL/TLS ellen 2012 szeptemberében az ekoparty 2012 biztonsági konferencián "A CRIME Attack" címmel (előadás PDF formátumban).
A CRIME jelentése:C.tömörítés R.atio ÉN.nfo-szivárgás M.szamár E.xploitation "(vagy". M.viszontlátásra E.asy "), és lehetővé teszi például a munkamenet-sütik dekódolását egy HTTPS-kapcsolattól. A sikeres támadás előfeltétele, hogy
- a támadó megfigyelheti az áldozat hálózati forgalmát, például azért, mert mindkettő megosztott nyílt WLAN-t és
- az áldozat rosszindulatú vagy megfelelően előkészített webhelyet látogat meg. A támadó ezt követően JavaScript-kódot injektál a támadást végrehajtó áldozat böngészőjébe.
Természetesen mindkettő különösen igaz, ha a támadó emberként viselkedhet.
Ezenkívül az ügyfélnek és a szervernek tömörítést kell használnia, például a TLS deflate tömörítését vagy az alkalmazásszintű tömörítést, például az SPDY-t.
A támadó ezután megfigyelheti a továbbított kérések hosszát, és az elküldött adatok ügyes manipulálásával megfejtheti vagy jobb esetben kitalálhatja azok egy részét. Ha a támadó által manipulált kérelem egyes részei egyeznek, például a munkamenet-süti, a kérelem hossza ennek megfelelően csökken. Így lépésről lépésre meghatározható a süti értéke. Egy videó bemutatja a támadást.
Ellenintézkedések
A CRIME támadás megakadályozható a HTTPS kapcsolatok tömörítésének kikapcsolásával. A böngészőket azóta ennek megfelelően javították, ha érintettek.
Következtetés
Összefoglalva elmondható, hogy az SSL/TLS mint protokoll még korántsem halt meg, és a TLS 1.2-vel elérhető egy biztonságos új verzió.
Az alkalmazott tanúsítási rendszerrel rosszabbul néz ki, túl gyakran "hamisított" (jobb: tévesen kiadott) vagy más módon problémás tanúsítványok jelennek meg. Leegyszerűsítve: A tanúsítási rendszer a bizalomra épül, és a tanúsító testületek újra és újra bebizonyítják, hogy nem érdemelnek bizalmat. Tehát ezen a ponton sürgősen változtatásokra van szükség.
Trackbackek
Dipl.-Inform. Carsten Eilers 2013. április 2-án, kedden: Hírek Java verziókról, Android-csomagokról, rootkit-ről és SSL/TLS-ről
Dipl.-Inform. Carsten Eilers 2015. április 14-én, kedden: SSL/TLS - ismét rossz hír!
Dipl.-Inform. Carsten Eilers 2015. május 13-án, szerdán: Nyomtatott anyagok: PHP Magazin 4.2015 - Cross-Side Request Forgery
Dipl.-Inform. Carsten Eilers 2015. december 21-én, hétfőn: Új e-könyv: "Webbiztonság - támadások SSRF, CSRF és XML használatával"
Oldalsáv
Rólam.
Dipl.-Inform. Carsten Eilers
Kövess engem.
Aktuális bejegyzések
Kategóriák
naptár
| ← Vissza | '20. December | |||||
| 1 | 2 | 3 | 4 | 5. | 6. | |
| 7. | 8. | 9. | 10. | 11. | 12. | 13. |
| 14-én | 15-én | 16. | 17-én | 18 | 19-én | 20 |
| 21. | 22-én | 23. | 24. | 25-én | 26-án | 27. |
| 28. | 29. | 30-án | 31 | |||
archívum
Téged feltört!
Téged feltört!
Könyv, 578 oldal
2018. december, Rheinwerk Computing
ISBN: 978-3-8362-4460-2
E-könyvként is elérhető
iOS biztonság
iOS biztonság
Könyv, 274 oldal
2014. január, developer.press
ISBN: 978-3-86802-101-1
Elérhető PDF és ePub-eBook formátumban is
Web biztonság
Web biztonság
E-könyv EPUB formátumban
2015. december, developer.press
ISBN: 978-3-86802-569-9
Adatbiztonság
Adatbiztonság
E-könyv EPUB formátumban
2015. november, developer.press
ISBN: 978-3-86802-568-2
Webbiztonsági éves áttekintés 2014
Webbiztonsági éves áttekintés 2014
E-könyv EPUB formátumban
2015. március, developer.press
ISBN: 978-3-86802-537-8
JavaScript biztonság
JavaScript biztonság
E-könyv EPUB formátumban
2015. január, developer.press
ISBN: 978-3-86802-531-6
Cél felhasználói felület
Cél felhasználói felület
E-könyv EPUB formátumban
2015. január, developer.press
ISBN: 978-3-86802-532-3
Android Security
Android Security
E-könyv EPUB formátumban
2014. október, developer.press
ISBN: 978-3-86802-521-7
Titkosítás az NSA korában
Titkosítás az NSA korában
E-könyv EPUB formátumban
2014. június, developer.press
ISBN: 978-3-86802-508-8
HTML5 biztonság
HTML5 biztonság
E-könyv EPUB formátumban
2012. május, developer.press
ISBN: 978-3-86802-417-3
A Serendipity & a 2k11-CE téma.