információk az újról (CVE-2020-1968) a TLS protokollban, kódnéven
és ritka esetekben lehetővé teszi egy előzetes elsődleges kulcs (pre-master) meghatározását, amely felhasználható a TLS-kapcsolatok visszafejtésére, beleértve a HTTPS-t is, amikor a tranzit forgalom (MITM) elfog. Meg kell jegyezni, hogy a támadás gyakorlati megvalósítása nagyon nehézkes, és inkább elméleti jellegű. A támadás végrehajtásához a TLS-kiszolgáló meghatározott konfigurációjára és a szerver feldolgozási idejének nagyon pontos mérésére van szükség.
A probléma közvetlenül a TLS specifikációban van jelen, és csak a DH kulcscsere protokollon (Diffie-Hellman, TLS_DH_*") alapuló rejtjeleket használó kapcsolatokat érinti. Az ECDH titkosításokkal a probléma nem fordul elő, és biztonságosak maradnak. Csak az 1.2-es verzióig terjedő TLS protokollok sebezhetők, a TLS 1.3-at nem érinti a probléma. A sérülékenység azokban a TLS-megvalósításokban jelentkezik, amelyek a titkos DH titkos kulcsot használják különböző TLS-kapcsolatokon (ez a viselkedés az Alexa Top 4.4M szerverek körülbelül 1%-án fordul elő).
Az OpenSSL 1.0.2e és korábbi kiadásaiban a DH elsődleges kulcsot minden szerverkapcsolatban újra felhasználják, kivéve, ha az SSL_OP_SINGLE_DH_USE opció kifejezetten be van állítva. Az OpenSSL 1.0.2f óta az elsődleges DH kulcsot csak statikus DH titkosítások ("DH-*", pl. "DH-RSA-AES256-SHA") használatakor használják újra. A biztonsági rés nem jelenik meg az OpenSSL 1.1.1-ben, mivel ez az ág nem használ elsődleges DH-kulcsot, és nem használ statikus DH-rejtjeleket.
A DH kulcscsere módszer alkalmazásakor a kapcsolat mindkét oldala véletlenszerű privát kulcsokat generál (a továbbiakban „a” és „b” kulcs), amelyek alapján a nyilvános kulcsok (ga mod p és gb mod p) kiszámításra és elküldésre kerülnek. Miután mindegyik fél megkapta a nyilvános kulcsokat, egy közös elsődleges kulcs (gab mod p) kerül kiszámításra, amelyet a munkamenetkulcsok generálására használnak. A Raccoon támadás lehetővé teszi az elsődleges kulcs meghatározását oldalcsatorna-elemzésen keresztül, azon a tényen alapulva, hogy a TLS-specifikációk az 1.2-es verzióig megkövetelik, hogy az elsődleges kulcs összes vezető nullbájtját el kell dobni a számítások előtt.
A csonkolt elsődleges kulcs belefoglalása a munkamenetkulcs-generáló funkcióba kerül, amely különböző adatok feldolgozásakor eltérő késleltetésű hash-függvényeken alapul. A kiszolgáló által végrehajtott kulcsműveletek időzítésének pontos mérése lehetővé teszi a támadó számára, hogy olyan nyomokat (oracle) határozzon meg, amelyek lehetővé teszik annak megítélését, hogy az elsődleges kulcs a nulláról indul-e vagy sem. Például egy támadó elkaphatja az ügyfél által küldött nyilvános kulcsot (ga), újraküldheti azt a szervernek, és meghatározhatja
hogy a kapott elsődleges kulcs nulláról indul-e.
Önmagában a kulcs egy bájtjának meghatározása nem ad semmit, de a kapcsolat egyeztetése során a kliens által továbbított „ga” érték elfogásával a támadó a „ga”-hoz társított egyéb értékeket generálhat, és elküldheti a a szervert külön kapcsolat-tárgyalási munkamenetekben. A „gri*ga” értékek generálásával és elküldésével a támadó a szerver válaszában bekövetkezett késések változásainak elemzésével meghatározhatja azokat az értékeket, amelyek nullától kezdődően az elsődleges kulcsok fogadásához vezetnek. Az ilyen értékek meghatározása után a támadó egyenletkészletet hozhat létre a számára és kiszámítja az eredeti elsődleges kulcsot.
OpenSSL biztonsági rések alacsony a veszély szintje, és a javítás a problémás „TLS_DH_*” rejtjelek 1.0.2w kiadásában az elégtelen védelmi szinttel rendelkező rejtjelek kategóriájába ("weak-ssl-ciphers") került áthelyezésre, amely alapértelmezés szerint le van tiltva. . A Mozilla fejlesztői ugyanezt tették, a Firefoxban használt NSS-könyvtárban, a DH és DHE titkosítási csomagokban. A Firefox 78-tól kezdve a problémás titkosítások le vannak tiltva. A Chrome DH-támogatása 2016-ban megszűnt. A BearSSL, BoringSSL, Botan, Mbed TLS és s2n könyvtárakat nem érinti a probléma, mert nem támogatják a DH titkosításokat vagy a DH titkosítások statikus változatait.
A további problémákat külön jelezzük () az F5 BIG-IP eszközök TLS-vermében, így a támadás valósághűbbé válik. Különösen az eszközök viselkedésében mutatkozó eltéréseket azonosították az elsődleges kulcs elején nulla bájt jelenléte esetén, amelyek felhasználhatók a számítások pontos késleltetésének mérése helyett.
Forrás: opennet.ru