impormasyon tungkol sa bago (CVE-2020-1968) sa TLS protocol, na may codenamed
at nagbibigay-daan, sa mga bihirang pagkakataon, upang matukoy ang isang paunang pangunahing key (pre-master), na maaaring magamit upang i-decrypt ang mga koneksyon sa TLS, kabilang ang HTTPS, kapag humarang sa trapiko ng transit (MITM). Nabanggit na ang pag-atake ay napakahirap para sa praktikal na pagpapatupad at higit pa sa isang teoretikal na kalikasan. Upang magsagawa ng pag-atake, kinakailangan ang isang partikular na configuration ng TLS server at ang kakayahang tumpak na sukatin ang oras ng pagproseso ng server.
Direktang naroroon ang problema sa detalye ng TLS at nakakaapekto lamang sa mga koneksyon gamit ang mga cipher batay sa DH key exchange protocol (Diffie-Hellman, TLS_DH_*"). Sa mga ECDH cipher ang problema ay hindi nangyayari at nananatili silang ligtas. Tanging ang mga protocol ng TLS hanggang sa bersyon 1.2 ang mahina; ang TLS 1.3 ay hindi apektado ng problema. Ang kahinaan ay nangyayari sa mga pagpapatupad ng TLS na muling ginagamit ang DH secret key sa iba't ibang TLS na koneksyon (ang gawi na ito ay nangyayari sa humigit-kumulang 4.4% ng Alexa Top 1M server).
Sa OpenSSL 1.0.2e at mga naunang release, ang DH primary key ay muling ginagamit sa lahat ng koneksyon sa server maliban kung ang SSL_OP_SINGLE_DH_USE na opsyon ay tahasang itinakda. Mula noong OpenSSL 1.0.2f, ang pangunahing key ng DH ay ginagamit lamang kapag gumagamit ng mga static na DH cipher ("DH-*", hal. "DH-RSA-AES256-SHA"). Ang kahinaan ay hindi lumalabas sa OpenSSL 1.1.1, dahil ang branch na ito ay hindi gumagamit ng DH primary key at hindi gumagamit ng mga static na DH cipher.
Kapag ginagamit ang paraan ng pagpapalitan ng DH key, ang magkabilang panig ng koneksyon ay bumubuo ng mga random na pribadong key (simula dito key "a" at key "b"), batay sa kung aling mga pampublikong key (ga mod p at gb mod p) ang kinakalkula at ipinapadala. Pagkatapos matanggap ng bawat partido ang mga pampublikong key, isang karaniwang pangunahing key (gab mod p) ang kinakalkula, na ginagamit upang bumuo ng mga session key. Binibigyang-daan ka ng pag-atake ng Raccoon na matukoy ang pangunahing key sa pamamagitan ng pagsusuri sa side-channel, batay sa katotohanan na ang mga detalye ng TLS hanggang sa bersyon 1.2 ay nangangailangan na ang lahat ng nangungunang null byte ng pangunahing key ay itapon bago ang mga kalkulasyon na kinasasangkutan nito.
Ang pagsasama ng pinutol na pangunahing key ay ipinapasa sa session key generation function, na nakabatay sa hash function na may iba't ibang pagkaantala kapag nagpoproseso ng iba't ibang data. Ang tumpak na pagsukat sa timing ng mga pangunahing operasyon na isinagawa ng server ay nagbibigay-daan sa umaatake na matukoy ang mga pahiwatig (oracle) na ginagawang posible upang hatulan kung ang pangunahing key ay nagsisimula sa simula o hindi. Halimbawa, maaaring harangin ng isang umaatake ang pampublikong key (ga) na ipinadala ng kliyente, muling ipadala ito sa server at matukoy
kung magsisimula sa zero ang resultang primary key.
Sa sarili nitong, ang pagtukoy ng isang byte ng susi ay hindi nagbibigay ng anuman, ngunit sa pamamagitan ng pagharang sa halaga ng "ga" na ipinadala ng kliyente sa panahon ng negosasyon sa koneksyon, ang umaatake ay maaaring makabuo ng isang hanay ng iba pang mga halaga na nauugnay sa "ga" at ipadala ang mga ito sa ang server sa magkahiwalay na sesyon ng negosasyon sa koneksyon. Sa pamamagitan ng pagbuo at pagpapadala ng mga halaga ng "gri*ga", matukoy ng isang attacker, sa pamamagitan ng pagsusuri sa mga pagbabago sa mga pagkaantala sa tugon ng server, ang mga halaga na humahantong sa pagtanggap ng mga pangunahing key simula sa zero. Ang pagkakaroon ng natukoy na mga halaga, ang umaatake ay maaaring lumikha ng isang hanay ng mga equation para sa at kalkulahin ang orihinal na pangunahing key.
Mga kahinaan sa OpenSSL mababang antas ng panganib, at ang pag-aayos ay nabawasan sa paglipat ng mga may problemang cipher na "TLS_DH_*" sa release 1.0.2w sa kategorya ng mga cipher na may hindi sapat na antas ng proteksyon ("weak-ssl-ciphers"), na hindi pinagana bilang default . Ginawa ng mga developer ng Mozilla ang parehong bagay, sa NSS library na ginagamit sa Firefox, ang DH at DHE cipher suite. Sa Firefox 78, ang mga may problemang cipher ay hindi pinagana. Ang suporta ng Chrome para sa DH ay hindi na ipinagpatuloy noong 2016. Ang BearSSL, BoringSSL, Botan, Mbed TLS at s2n library ay hindi apektado ng problema dahil hindi nila sinusuportahan ang mga DH cipher o static na variant ng DH ciphers.
Ang mga karagdagang problema ay binanggit nang hiwalay () sa TLS stack ng F5 BIG-IP device, na ginagawang mas makatotohanan ang pag-atake. Sa partikular, natukoy ang mga paglihis sa pag-uugali ng mga device sa pagkakaroon ng zero byte sa simula ng pangunahing key, na maaaring gamitin sa halip na sukatin ang eksaktong latency ng mga kalkulasyon.
Pinagmulan: opennet.ru