30 mai a expirat perioada de valabilitate de 20 de ani a certificatul rădăcină , care 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.
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ă 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 multor infrastructuri care utilizează canale de comunicare criptate pentru interacțiunea între componente.
De exemplu, au apărut 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, funcționarea platformei de streaming Roku, au încetat apelurile către procesatori și , au început în aplicațiile Heroku, 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 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ă TLS.
, problema afectează versiunile mai vechi ale distribuțiilor (inclusiv Debian 9, Ubuntu 16.04, ) în care sunt utilizate branșele problematice OpenSSL, dar problema 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 . În OpenSSL problema a fost rezolvată în branșa 1.1.1, iar în rămâne .
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 și 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ă pentru GnuTLS (de exemplu, continuă să emită o eroare de verificare a certificatului la rularea utilitarului wget).
Pe partea serverului, se poate 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 . Compania Sectigo a furnizat, de asemenea, certificat intermediar semnat încrucișat alternativ „„, 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 în LibreSSL.
Sursa: opennet.ro
