Îmbătrânirea certificatului rădăcină AddTrust a dus la erori în sistemele cu OpenSSL și GnuTLS

30 mai a expirat perioada de valabilitate de 20 de ani a certificatul rădăcină AddTrust, care se utiliza pentru a forma o semnătură încrucișată (cross-signed) în certificatul unuia dintre cei mai mari furnizori de servicii de certificare, Sectigo (Comodo). Semnătura încrucișată permitea asigurarea compatibilității cu dispozitivele învechite, în depozitul certificatelor rădăcină ale căror nu a fost adăugat noul certificat rădăcină USERTrust.

Îmbătrânirea certificatului rădăcină AddTrust a dus la erori în sistemele cu OpenSSL și GnuTLS

Teoretic, expirarea certificatului rădăcină AddTrust ar fi trebuit să ducă doar la o încălcare a compatibilității cu sistemele vechi (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 ș.a.), deoarece cel de-al doilea certificat rădăcină folosit în semnătura încrucișată rămâne valabil și browserele moderne îl iau în considerare în timpul verificării lanțului de încredere. În practică s-au descoperit probleme cu verificarea semnăturii încrucișate în clienții TLS care nu folosesc browsere, inclusiv cele bazate pe OpenSSL 1.0.x și GnuTLS. Conexiunea securizată a încetat să se stabilească, cu un mesaj de eroare despre expirarea certificatului, atunci când pe server este utilizat certificatul Sectigo, conectat prin lanțul de încredere cu certificatul rădăcină AddTrust.

Dacă utilizatorii browserelor moderne nu au observat expirarea certificatului rădăcină AddTrust în timpul procesării certificatelor semnate încrucișat de Sectigo, atunci în diverse aplicații terțe și procesatoare de servere au început să apară probleme, ceea ce a condus la la o întrerupere funcționarea multor infrastructuri care utilizează canale de comunicare criptate pentru interacțiunea între componente.

De exemplu, au apărut probleme probleme cu accesarea unor depozite de pachete în Debian și Ubuntu (apt a început să returneze o eroare de verificare a certificatului), apelurile din scripturi utilizând utilitarele „curl” și „wget” au început să eșueze, iar erori sunt observate la utilizarea Git, s-a întrerupt funcționarea platformei de streaming Roku, au încetat apelurile către procesatori Stripe și DataDog, au început să apară erori în aplicațiile Heroku, au încetat să se conecteze clienții OpenLDAP, fiind raportate probleme cu trimiterea de emailuri către serverele SMTPS și SMTP cu STARTTLS. În plus, se observă probleme în diverse scripturi Ruby, PHP și Python, care folosesc un modul cu client http. Din browsere, problema implică Epiphany, în care listele de blocare a reclamelor nu mai pot fi încărcate.

Programele scrise în Go nu sunt afectate de problemă, deoarece în Go se oferă o implementare proprie TLS.

Se presupunea, problema afectează versiunile mai vechi ale distribuțiilor (inclusiv Debian 9, Ubuntu 16.04, RHEL 6/7) în care sunt utilizate branșele problematice OpenSSL, dar problema s-a manifestat de asemenea în gestionarea pachetelor APT în versiunile curente Debian 10 și Ubuntu 18.04/20.04, deoarece APT utilizează biblioteca GnuTLS. Esența problemei este că multe biblioteci TLS/SSL interpretează certificatul ca un lanț liniar, în timp ce conform RFC 4158 certificatul poate reprezenta un graf distribuit orientat ciclic cu mai multe ancore de încredere care trebuie luate în considerare. Această deficiență în OpenSSL și GnuTLS să aibă se știe există de mulți ani. În OpenSSL problema a fost rezolvată în branșa 1.1.1, iar în GnuTLS rămâne necorectată.

Ca o soluție temporară pentru a elimina defecțiunea, se propune eliminarea certificatului „AddTrust External CA Root” din depozitul de sisteme (de exemplu, eliminarea din /etc/ca-certificates.conf și /etc/ssl/certs, apoi rularea „update-ca-certificates -f -v”), după care OpenSSL începe să proceseze corect certificatele semnate încrucișat în care este implicat. Când se utilizează gestionarul de pachete APT, se pot dezactiva verificările certificatelor pentru anumite cereri pe riscul utilizatorului (de exemplu, „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false”).

Pentru a bloca problema în Fedora și RHEL se propune adăugarea certificatului AddTrust în lista neagră:

dump de încredere —filtrare «pkcs11:id=;tip=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Dar această metodă nu funcționează pentru GnuTLS (de exemplu, continuă să emită o eroare de verificare a certificatului la rularea utilitarului wget).

Pe partea serverului, se poate schimba ordonarea certificatelor în lanțul de încredere trimis serverului către client (dacă certificatul asociat cu „AddTrust External CA Root” este eliminat din listă, verificarea de către client va avea succes). Pentru a verifica și genera un nou lanț de încredere, se poate utiliza serviciul whatsmychaincert.com. Compania Sectigo a furnizat, de asemenea, un certificat intermediar semnat încrucișat alternativ „AAA Certificate Services„, care va fi valabil până în 2028 și va permite menținerea compatibilității cu versiunile anterioare ale sistemului de operare.

Adăugare: Problema există și se manifestă în LibreSSL.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster