Kwetsberens yn TLS wêrtroch kaaibepaling mooglik is foar ferbiningen basearre op DH-sifers

Revealed ynformaasje oer de nije kwetsberens (CVE-2020-1968) yn it TLS-protokol, koadenamme
Wasbeer en tastean, yn seldsume omstannichheden, te bepalen in foarriedige primêre kaai (pre-master), dat kin brûkt wurde om te ûntsiferjen TLS ferbinings, ynklusyf HTTPS, by it ûnderskeppen fan transit ferkear (MITM). It wurdt opmurken dat de oanfal is hiel lestich foar praktyske ymplemintaasje en is mear fan in teoretyske natuer. Om in oanfal út te fieren, binne in spesifike konfiguraasje fan 'e TLS-tsjinner en de mooglikheid om de ferwurkingstiid fan 'e server tige sekuer te mjitten.

It probleem is direkt oanwêzich yn 'e TLS-spesifikaasje en hat allinich ynfloed op ferbiningen mei sifers basearre op it DH-kaai-útwikselprotokol (Diffie-Hellman, TLS_DH_*"). Mei ECDH-sifers komt it probleem net foar en bliuwe se feilich. Allinich TLS-protokollen oant ferzje 1.2 binne kwetsber; TLS 1.3 wurdt net beynfloede troch it probleem. De kwetsberens komt foar yn TLS-ymplemintaasjes dy't de geheime DH-kaai opnij brûke oer ferskate TLS-ferbiningen (dit gedrach komt foar op sawat 4.4% fan Alexa Top 1M-tsjinners).

Yn OpenSSL 1.0.2e en eardere releases wurdt de primêre DH-kaai opnij brûkt yn alle tsjinnerferbiningen, útsein as de opsje SSL_OP_SINGLE_DH_USE eksplisyt ynsteld is. Sûnt OpenSSL 1.0.2f wurdt de primêre DH-kaai allinich opnij brûkt by it brûken fan statyske DH-sifers ("DH-*", bygelyks "DH-RSA-AES256-SHA"). De kwetsberens ferskynt net yn OpenSSL 1.1.1, om't dizze tûke gjin DH-primêre kaai brûkt en gjin statyske DH-sifers brûkt.

By it brûken fan de DH kaai útwikseling metoade, beide kanten fan de ferbining generearje willekeurige privee kaaien (hjirnei kaai "a" en kaai "b"), basearre op hokker iepenbiere kaaien (ga mod p en gb mod p) wurde berekkene en ferstjoerd. Nei't elke partij de iepenbiere kaaien ûntfangt, wurdt in mienskiplike primêre kaai (gab mod p) berekkene, dy't brûkt wurdt om sesjekaaien te generearjen. De Raccoon-oanfal lit jo de primêre kaai bepale fia side-kanaalanalyse, basearre op it feit dat de TLS-spesifikaasjes oant ferzje 1.2 fereaskje dat alle liedende nulbytes fan 'e primêre kaai wurde ferwidere foardat berekkeningen dêrby binne.

Ynklusyf de ôfkoarte primêre kaai wurdt trochjûn oan de sesjekaaigeneraasjefunksje, dy't basearre is op hashfunksjes mei ferskate fertragingen by it ferwurkjen fan ferskate gegevens. Akkuraat mjitten fan de timing fan kaai operaasjes útfierd troch de tsjinner lit de oanfaller te bepalen oanwizings (oracle) dy't meitsje it mooglik om te oardieljen oft de primêre kaai begjint fanôf it begjin of net. Bygelyks, in oanfaller koe de iepenbiere kaai (ga) ûnderskeppe dy't troch de kliïnt stjoerd is, it opnij oerstjoere nei de tsjinner en bepale
oft de resultearjende primêre kaai begjint fan nul.

Op himsels jout it definiearjen fan ien byte fan 'e kaai neat, mar troch de "ga"-wearde te ûnderskeppen dy't troch de kliïnt oerbrocht wurdt tidens ferbiningsûnderhanneling, kin de oanfaller in set fan oare wearden generearje dy't ferbûn binne mei "ga" en stjoere se nei de tsjinner yn aparte ferbining ûnderhannelings sesjes. Troch "gri*ga"-wearden te generearjen en te ferstjoeren, kin in oanfaller, troch it analysearjen fan feroaringen yn fertragingen yn 'e serverantwurd, de wearden bepale dy't liede ta it ûntfangen fan primêre kaaien begjinnend fan nul. Nei it fêststellen fan sokke wearden, de oanfaller kin meitsje in set fan fergelikingen foar oplossings ferburgen nûmer problemen en berekkenje de oarspronklike primêre kaai.

Kwetsberens yn TLS wêrtroch kaaibepaling mooglik is foar ferbiningen basearre op DH-sifers

OpenSSL kwetsberens tawiisd leech nivo fan gefaar, en de fix waard ferlege ta it ferpleatsen fan de problematyske sifers "TLS_DH_*" yn release 1.0.2w nei de kategory fan sifers mei in net genôch nivo fan beskerming ("swak-ssl-sifers"), dy't standert útskeakele is . De Mozilla-ûntwikkelders diene itselde ding, útsetten yn 'e NSS-bibleteek brûkt yn Firefox, de DH- en DHE-sifersuites. Fanôf Firefox 78 binne problematyske sifers útskeakele. Chrome-stipe foar DH waard yn 2016 stopset. De BearSSL, BoringSSL, Botan, Mbed TLS en s2n bibleteken wurde net beynfloede troch it probleem, om't se gjin DH-sifers stypje of statyske farianten fan DH-sifers.

Oanfoljende problemen wurde apart notearre (CVE-2020-5929) yn 'e TLS-stapel fan F5 BIG-IP-apparaten, wêrtroch't de oanfal realistysk is. Benammen ôfwikingen yn it gedrach fan apparaten yn 'e oanwêzigens fan in nul byte oan it begjin fan' e primêre kaai binne identifisearre, dy't brûkt wurde kinne ynstee fan it mjitten fan 'e krekte latency fan berekkeningen.

Boarne: opennet.ru

Add a comment