informoj pri la nova (CVE-2020-1968) en la TLS-protokolo, kodita
kaj permesante, en maloftaj cirkonstancoj, determini preparan primaran ŝlosilon (antaŭ-majstro), kiu povas esti uzita por deĉifri TLS-ligojn, inkluzive de HTTPS, dum kaptado de transittrafiko (MITM). Oni rimarkas, ke la atako estas tre malfacila por praktika efektivigo kaj estas pli de teoria naturo. Por fari atakon, necesas specifa agordo de la TLS-servilo kaj la kapablo tre precize mezuri la servilan pretigtempon.
La problemo ĉeestas rekte en la TLS-specifo kaj nur influas ligojn uzantajn ĉifrojn bazitajn sur la DH-ŝlosila interŝanĝprotokolo (Diffie-Hellman, TLS_DH_*"). Kun ECDH-ĉifroj la problemo ne okazas kaj ili restas sekuraj. Nur TLS-protokoloj ĝis versio 1.2 estas vundeblaj; TLS 1.3 ne estas tuŝita de la problemo. La vundebleco okazas en TLS-efektivigoj, kiuj reuzas la sekretan ŝlosilon DH tra malsamaj TLS-konektoj (ĉi tiu konduto okazas sur proksimume 4.4% de Alexa Top 1M-serviloj).
En OpenSSL 1.0.2e kaj pli fruaj eldonoj, la DH-ĉefa ŝlosilo estas reuzata en ĉiuj servilaj konektoj krom se la opcio SSL_OP_SINGLE_DH_USE estas eksplicite agordita. Ekde OpenSSL 1.0.2f, la DH-ĉefa ŝlosilo estas nur reuzata dum uzado de senmovaj DH-ĉifroj ("DH-*", ekz. "DH-RSA-AES256-SHA"). La vundebleco ne aperas en OpenSSL 1.1.1, ĉar ĉi tiu branĉo ne uzas DH-ĉefan ŝlosilon kaj ne uzas senmovajn DH-ĉifrojn.
Kiam oni uzas la DH-ŝlosilŝanĝan metodon, ambaŭ flankoj de la konekto generas hazardajn privatajn ŝlosilojn (ĉi-poste ŝlosilo "a" kaj ŝlosilo "b"), surbaze de kiuj publikaj ŝlosiloj (ga mod p kaj gb mod p) estas kalkulitaj kaj senditaj. Post kiam ĉiu partio ricevas la publikajn ŝlosilojn, komuna primara ŝlosilo (gab mod p) estas kalkulita, kiu estas uzata por generi sesioŝlosilojn. La Raccoon-atako permesas vin determini la primaran ŝlosilon per flankkanala analizo, surbaze de tio, ke la TLS-specifoj ĝis versio 1.2 postulas, ke ĉiuj ĉefaj nulaj bajtoj de la primara ŝlosilo estu forĵetitaj antaŭ kalkuloj implikantaj ĝin.
Inkluzive de la detranĉita primara ŝlosilo estas transdonita al la sesioŝlosila genera funkcio, kiu baziĝas sur hash-funkcioj kun malsamaj prokrastoj dum prilaborado de malsamaj datumoj. Precize mezuri la tempon de ŝlosilaj operacioj faritaj de la servilo permesas al la atakanto determini indicojn (orakolo) kiuj ebligas juĝi ĉu la primara ŝlosilo komenciĝas de nulo aŭ ne. Ekzemple, atakanto povus kapti la publikan ŝlosilon (ga) senditan de la kliento, retranssendi ĝin al la servilo kaj determini
ĉu la rezulta ĉefŝlosilo komenciĝas de nulo.
Per si mem, difini unu bajton de la ŝlosilo ne donas ion ajn, sed kaptante la "ga" valoron transdonitan de la kliento dum konektointertraktado, la atakanto povas generi aron da aliaj valoroj asociitaj kun "ga" kaj sendi ilin al. la servilo en apartaj intertraktadsesioj. Generante kaj sendante "gri*ga" valorojn, la atakanto povas, per analizado de ŝanĝoj en prokrastoj en la servila respondo, determini la valorojn kiuj kondukas al ricevi primarajn ŝlosilojn ekde nulo. Determininte tiajn valorojn, la atakanto povas krei aron de ekvacioj por kaj kalkulu la originan ĉefan ŝlosilon.
OpenSSL-vundeblecoj malalta nivelo de danĝero, kaj la riparo estis reduktita al movi la problemajn ĉifrojn "TLS_DH_*" en eldono 1.0.2w al la kategorio de ĉifroj kun nesufiĉa nivelo de protekto ("malfortaj-ssl-ĉifroj"), kiu estas malebligita defaŭlte. . La programistoj de Mozilla faris la samon, en la NSS-biblioteko uzita en Fajrovulpo, la DH kaj DHE-ĉifrosuoj. Ekde Firefox 78, problemaj ĉifroj estas malŝaltitaj. Chrome faligis subtenon por DH reen en 2016. La bibliotekoj BearSSL, BoringSSL, Botan, Mbed TLS kaj s2n ne estas tuŝitaj de la problemo ĉar ili ne subtenas DH-ĉifrojn aŭ senmovajn variantojn de DH-ĉifroj.
Pliaj problemoj estas notitaj aparte () en la TLS-stako de F5 BIG-IP-aparatoj, farante la atakon pli realisma. Aparte, devioj en la konduto de aparatoj en la ĉeesto de nul bajto komence de la primara ŝlosilo estis identigitaj, kiu povas esti uzata anstataŭ mezuri la ĝustan latentecon de kalkuloj.
fonto: opennet.ru