30. května vypršela 20letá doba platnosti kořenového certifikátu Který pro vygenerování křížově podepsaných certifikátů jedné z největších certifikačních autorit Sectigo (Comodo). Křížové podepisování umožňovalo kompatibilitu se staršími zařízeními, která neměla nový kořenový certifikát USERTRust přidaný do jejich kořenového úložiště certifikátů.
Teoreticky by deaktivace kořenového certifikátu AddTrust měla vést pouze k narušení kompatibility se staršími systémy (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 atd.), protože druhý kořenový certifikát použitý v křížovém podpisu zůstává platný a moderní prohlížeče jej berou v úvahu při ověřování řetězce důvěryhodnosti. V praxi Problémy s ověřováním křížového podpisu v klientech TLS bez prohlížeče, včetně těch, které jsou založeny na OpenSSL 1.0.xa GnuTLS. Pokud server používá certifikát Sectigo propojený řetězem důvěry s kořenovým certifikátem AddTrust, již není navázáno zabezpečené připojení s chybou indikující, že certifikát je zastaralý.
Pokud si uživatelé moderních prohlížečů nevšimli zastaralosti kořenového certifikátu AddTrust při zpracování křížově podepsaných certifikátů Sectigo, pak se začaly objevovat problémy v různých aplikacích třetích stran a obslužných programech na straně serveru, což vedlo k mnoho infrastruktur, které používají šifrované komunikační kanály pro interakci mezi komponentami.
Například tam byly s přístupem k některým repozitářům balíčků v Debian и Ubuntu (apt začal vracet chybu ověření certifikátu), požadavky na skripty používající utility „curl“ a „wget“ začaly selhávat, při používání Gitu byly pozorovány chyby, Streamovací platforma Roku funguje, handlery již nejsou volány и , začal v aplikacích Heroku, Klienti OpenLDAP se připojují, jsou detekovány problémy s odesíláním pošty na servery SMTPS a SMTP s STARTTLS. Kromě toho jsou problémy pozorovány v různých skriptech Ruby, PHP a Python, které používají modul s klientem http. Problém s prohlížečem Epiphany, která přestala načítat seznamy blokování reklam.
Programů Go se tento problém netýká, protože Go nabízí TLS.
, že problém se týká starších verzí distribucí (včetně Debian 9, Ubuntu 16.04, ), které používají problematické větve OpenSSL, ale problém také při spuštění správce balíčků APT v aktuálních verzích Debian 10 a Ubuntu 18.04. dubna 20.04, protože APT používá knihovnu GnuTLS. Problém je v tom, že mnoho knihoven TLS/SSL analyzuje certifikát jako lineární řetězec, zatímco podle RFC 4158 může certifikát představovat orientovaný distribuovaný cyklický graf s více kotvami důvěryhodnosti, které je třeba zvážit. Tento problém je řešen v OpenSSL a GnuTLS. . V OpenSSL byl problém opraven ve větvi 1.1.1 a v Zůstává .
Jako náhradní řešení se doporučuje odebrat certifikát „AddTrust External CA Root“ ze systémového úložiště (například odebrat z /etc/ca-certificates.conf a /etc/ssl/certs a poté spustit „update-ca -certificates -f -v"), poté OpenSSL začne normálně zpracovávat křížově podepsané certifikáty se svou účastí. Při používání správce balíčků APT můžete zakázat ověřování certifikátů pro jednotlivé požadavky na vlastní nebezpečí (například „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false“). .
Chcete-li problém zablokovat и Navrhuje se přidat certifikát AddTrust na černou listinu:
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 extrakt
Ale tato metoda pro GnuTLS (například při spuštění nástroje wget se stále zobrazuje chyba ověření certifikátu).
Na straně serveru můžete výpis certifikátů v řetězci důvěryhodnosti odeslaných serverem klientovi (pokud je certifikát spojený s „AddTrust External CA Root“ odstraněn ze seznamu, ověření klienta bude úspěšné). Chcete-li zkontrolovat a vygenerovat nový řetězec důvěry, můžete použít službu . Sectigo také alternativní křížově podepsaný přechodný certifikát "“, který bude platný do roku 2028 a zachová si kompatibilitu se staršími verzemi OS.
Dodatek: Problém také v LibreSSL.
Zdroj: opennet.ru
