Ang paghinto sa paggamit ng AddTrust root certificate ay nagdudulot ng mga pag-crash sa OpenSSL at GnuTLS system

Noong Mayo 30, nag-expire ang 20 taong validity period ng root certificate AddTrustAlin inilapat upang makabuo ng isang cross-sign in na mga sertipiko ng isa sa pinakamalaking awtoridad sa sertipikasyon na Sectigo (Comodo). Pinapayagan ang cross-signing para sa compatibility sa mga legacy na device na walang bagong USERTRust root certificate na idinagdag sa kanilang root certificate store.

Ayon sa teorya, ang pagwawakas ng AddTrust root certificate ay dapat lang humantong sa isang paglabag sa compatibility sa mga legacy system (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, atbp.), dahil nananatili ang pangalawang root certificate na ginamit sa cross-signature. Isinasaalang-alang ito ng mga wasto at modernong browser kapag sinusuri ang chain of trust. Sa practice Nagpakita Mga problema sa cross-signature na pag-verify sa mga hindi browser na TLS client, kabilang ang mga nakabatay sa OpenSSL 1.0.x at GnuTLS. Ang isang secure na koneksyon ay hindi na naitatag na may error na nagsasaad na ang certificate ay luma na kung ang server ay gumagamit ng isang Sectigo certificate na naka-link ng isang chain of trust sa AddTrust root certificate.

Kung hindi napansin ng mga user ng modernong browser ang pagkaluma ng AddTrust root certificate kapag nagpoproseso ng mga cross-signed Sectigo certificate, nagsimulang mag-pop up ang mga problema sa iba't ibang third-party na application at server-side handler, na humantong sa paglabag magtrabaho maraming mga imprastraktura na gumagamit ng mga naka-encrypt na channel ng komunikasyon para sa pakikipag-ugnayan sa pagitan ng mga bahagi.

Halimbawa, nagkaroon problema na may access sa ilang mga repository ng package sa Debian at Ubuntu (nagsimulang bumuo ng error sa pag-verify ng certificate), ang mga kahilingan mula sa mga script gamit ang "curl" at "wget" na mga utility ay nagsimulang mabigo, ang mga error ay naobserbahan kapag gumagamit ng Git, nilabag Gumagana ang Roku streaming platform, hindi na tinatawag ang mga handler Guhit и DataDog, nagsimula nagaganap ang mga pag-crash sa Heroku apps, huminto Kumonekta ang mga kliyente ng OpenLDAP, natukoy ang mga problema sa pagpapadala ng mail sa mga SMTPS at SMTP server na may STARTTLS. Bilang karagdagan, ang mga problema ay sinusunod sa iba't ibang Ruby, PHP at Python script na gumagamit ng isang module na may isang http client. Problema sa browser nakakaapekto Epiphany, na huminto sa pag-load ng mga listahan ng pagharang ng ad.

Ang mga programa ng Go ay hindi apektado ng problemang ito dahil nag-aalok ang Go sariling pagpapatupad TLS.

Ito ay ipinapalagayna ang problema ay nakakaapekto sa mas lumang mga release ng pamamahagi (kabilang ang Debian 9, Ubuntu 16.04, RHEL 6/7) na gumagamit ng problemadong mga sangay ng OpenSSL, ngunit ang problema ipinahayag ang sarili din kapag ang APT package manager ay tumatakbo sa mga kasalukuyang release ng Debian 10 at Ubuntu 18.04/20.04, dahil ang APT ay gumagamit ng GnuTLS library. Ang pinakabuod ng problema ay maraming TLS/SSL na library ang nag-parse ng isang certificate bilang isang linear chain, samantalang ayon sa RFC 4158, ang isang certificate ay maaaring kumatawan sa isang nakadirekta na distributed circular graph na may maraming trust anchor na kailangang isaalang-alang. Tungkol sa kapintasang ito sa OpenSSL at GnuTLS ito ay ay kilala Sa loob ng maraming taon. Sa OpenSSL ang problema ay naayos sa branch 1.1.1, at sa gnuTLS labi hindi naitama.

Bilang isang solusyon, iminumungkahi na alisin ang certificate na “AddTrust External CA Root” mula sa system store (halimbawa, alisin mula sa /etc/ca-certificates.conf at /etc/ssl/certs, at pagkatapos ay patakbuhin ang “update-ca -certificates -f -v"), pagkatapos ay magsisimula ang OpenSSL na normal na magproseso ng mga cross-signed na certificate kasama ang paglahok nito. Kapag ginagamit ang APT package manager, maaari mong i-disable ang pag-verify ng certificate para sa mga indibidwal na kahilingan sa iyong sariling peligro (halimbawa, “apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false”) .

Upang harangan ang problema sa Fedora и RHEL Iminungkahi na idagdag ang AddTrust certificate sa blacklist:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Ngunit ang pamamaraang ito hindi gumagana para sa GnuTLS (halimbawa, isang error sa pag-verify ng certificate ay patuloy na lumalabas kapag pinapatakbo ang wget utility).

Sa server side kaya mo magbago order naglilista ng mga certificate sa trust chain na ipinadala ng server sa client (kung ang certificate na nauugnay sa “AddTrust External CA Root” ay aalisin sa listahan, kung gayon ang pag-verify ng kliyente ay magiging matagumpay). Para suriin at bumuo ng bagong chain of trust, maaari mong gamitin ang serbisyo whatsmychaincert.com. Sectigo din ibinigay alternatibong cross-signed intermediate certificate "Mga Serbisyo sa sertipiko ng AAA“, na magiging wasto hanggang 2028 at mapanatili ang pagiging tugma sa mga mas lumang bersyon ng OS.

Dagdag: Problema din ay ipinahayag sa LibreSSL.

Pinagmulan: opennet.ru