La 30-an de majo eksvalidiĝis la 20-jara valideco de la radika atestilo , kiu por generi krucsubskribitajn atestojn de unu el la plej grandaj atestaj aŭtoritatoj Sectigo (Comodo). Krucsubskribo permesis kongruon kun heredaj aparatoj kiuj ne havis la novan radikan atestilon USERTRust aldonitan al sia radika atestilbutiko.
Teorie, ĉesigo de la radika atestilo AddTrust devus nur konduki al malobservo de kongruo kun heredaj sistemoj (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, ktp.), ĉar la dua radika atestilo uzata en la krucsignaturo restas. validaj kaj modernaj retumiloj konsideras ĝin kiam kontrolas la ĉenon de fido. Pri praktiko Problemoj kun transsigna konfirmo en ne-retumiloj TLS-klientoj, inkluzive de tiuj bazitaj sur OpenSSL 1.0.x kaj GnuTLS. Sekura konekto ne plu estas establita kun eraro indikanta ke la atestilo estas malaktuala se la servilo uzas Sectigo-atestilon ligitan per ĉeno de fido al la radika atestilo AddTrust.
Se uzantoj de modernaj retumiloj ne rimarkis la malnoviĝon de la radika atestilo AddTrust dum la prilaborado de krucsubskribitaj Sectigo-atestiloj, tiam problemoj komenciĝis aperi en diversaj triapartaj aplikoj kaj servilflankaj prizorgantoj, kio kondukis al multaj infrastrukturoj kiuj uzas ĉifritajn komunikajn kanalojn por interagado inter komponentoj.
Ekzemple, estis kun aliro al iuj pakaĵdeponejoj en Debian kaj Ubuntu (apt komencis generi atestilkonfirman eraron), petoj de skriptoj uzantaj la "curl" kaj "wget"-servaĵojn komencis malsukcesi, eraroj estis observitaj dum uzado de Git, Roku-streaming-platformo funkcias, pritraktantoj ne plu estas vokitaj и , komencis en Heroku-aplikoj, Klientoj de OpenLDAP konektas, problemoj pri sendado de poŝto al SMTPS kaj SMTP-serviloj kun STARTTLS estas detektitaj. Krome, problemoj estas observataj en diversaj Ruby, PHP kaj Python-skriptoj, kiuj uzas modulon kun http-kliento. Retumila problemo Epiphany, kiu ĉesis ŝarĝi reklamajn blokajn listojn.
Go-programoj ne estas tuŝitaj de ĉi tiu problemo ĉar Go ofertas TLS.
ke la problemo influas pli malnovajn distribuajn eldonojn (inkluzive de Debian 9, Ubuntu 16.04, ) kiuj uzas problemajn OpenSSL-branĉojn, sed la problemo ankaŭ kiam la pakadministranto de APT funkcias en nunaj eldonoj de Debian 10 kaj Ubuntu 18.04/20.04, ĉar APT uzas la bibliotekon GnuTLS. La kerno de la problemo estas, ke multaj TLS/SSL-bibliotekoj analizas atestilon kiel lineara ĉeno, dum laŭ RFC 4158, atestilo povas reprezenti direktitan distribuitan cirklan grafeon kun multoblaj fidaj ankroj, kiujn oni devas konsideri. Pri ĉi tiu difekto en OpenSSL kaj GnuTLS . En OpenSSL la problemo estis riparita en branĉo 1.1.1, kaj en restas .
Kiel solvo, oni sugestas forigi la atestilon "AddTrust External CA Root" el la sistemvendejo (ekzemple, forigi el /etc/ca-certificates.conf kaj /etc/ssl/certs, kaj poste ruli "update-ca". -certificates -f -v"), post kio OpenSSL komencas normale prilabori krucsubskribitajn atestilojn kun sia partopreno. Kiam vi uzas la pakaĵadministrilon de APT, vi povas malebligi atestilkonfirmon por individuaj petoj je via propra risko (ekzemple, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false") .
Por bloki la problemon en и Oni proponas aldoni la atestilon AddTrust al la nigra listo:
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
Sed ĉi tiu metodo por GnuTLS (ekzemple, atestila konfirmeraro daŭre aperas dum rulado de la ilo wget).
Ĉe la servilo vi povas listigante la atestilojn en la fida ĉeno sendita de la servilo al la kliento (se la atestilo asociita kun "AddTrust External CA Root" estas forigita de la listo, tiam la konfirmo de la kliento estos sukcesa). Por kontroli kaj generi novan ĉenon de fido, vi povas uzi la servon . Sectigo ankaŭ alternativa krucsubskribita meza atestilo "", kiu validos ĝis 2028 kaj konservos kongruon kun pli malnovaj versioj de la OS.
Aldono: Problemo ankaŭ en LibreSSL.
fonto: opennet.ru