Prestarzałość głównego certyfikatu AddTrust prowadziła do awarii w systemach opartych na OpenSSL i GnuTLS

30 maja wygaśnięcie 20-letniego okresu ważności certyfikatu root. AddTrust, który używano w celu stworzenia podpisu krzyżowego (cross-signed) w certyfikatach jednego z największych urzędów certyfikacyjnych Sectigo (Comodo). Podpis krzyżowy zapewniał kompatybilność z przestarzałymi urządzeniami, w których magazynie certyfikatów głównych nie dodano nowego certyfikatu root USERTrust.

Teoretycznie wygaśnięcie certyfikatu root AddTrust powinno skutkować jedynie utratą kompatybilności z przestarzałymi systemami (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 itp.), ponieważ drugi certyfikat root, wykorzystywany w podpisie krzyżowym, pozostaje aktualny, a nowoczesne przeglądarki biorą go pod uwagę przy weryfikacji łańcucha zaufania. W praktyce pojawiły się problemy z weryfikacją podpisu krzyżowego w nieużywających przeglądarek klientach TLS, w tym tych opartych na OpenSSL 1.0.x i GnuTLS. Bezpieczne połączenie przestało być nawiązywane z komunikatem o błędzie związanym ze starością certyfikatu, jeśli na serwerze użyto certyfikatu Sectigo, powiązanego łańcuchem zaufania z certyfikatem root AddTrust.

Jeśli użytkownicy nowoczesnych przeglądarek nie zauważyli wygaśnięcia certyfikatu root AddTrust przy obsłudze certyfikatów podpisanych krzyżowo przez Sectigo, to w różnych aplikacjach zewnętrznych i serwerowych wystąpiły problemy, co doprowadziło do naruszeniu działania wielu infrastruktur, które korzystają z szyfrowanych kanałów komunikacyjnych do interakcji między komponentami.

Na przykład wystąpiły problemy problemy z dostępem do niektórych repozytoriów pakietów w Debianie i Ubuntu (apt zaczęło zgłaszać błąd weryfikacji certyfikatu), wystąpiły błędy w skryptach wykorzystujących narzędzia «curl» i «wget», zauważono błędy przy użyciu Git, zakłóciły się działania platformy streamingu Roku, przestały działać procedury Stripe i DataDog, zaczęły pojawiać się awarie w aplikacjach Heroku, przestały łączyć się klienci OpenLDAP, zauważono problemy z wysyłaniem wiadomości do serwerów SMTPS i SMTP z STARTTLS. Dodatkowo zaobserwowano problemy w różnych skryptach Ruby, PHP i Python, które korzystały z modułu z klientem http. Z przeglądarek problem rozwiązań opartych na otwartym stosie UPnP Epiphany, w której przestały się ładować listy blokad reklam.

Programy napisane w języku Go nie są narażone na problem, ponieważ w Go oferuje się własną implementację TLS.

Zakładając, że problem dotyczy starych wydań dystrybucji (w tym Debian 9, Ubuntu 16.04, RHEL 6/7) w których używane są problematyczne gałęzie OpenSSL, ale problem został ujawniony również podczas pracy menedżera pakietów APT w aktualnych wydaniach Debiana 10 i Ubuntu 18.04/20.04, ponieważ APT korzysta z biblioteki GnuTLS. Istota problemu polega na tym, że wiele bibliotek TLS/SSL interpretuje certyfikat jako liniowy ciąg, podczas gdy zgodnie z RFC 4158 certyfikat może przedstawiać ukierunkowany rozproszony cykliczny graf z wieloma punktami zaufania, które należy wziąć pod uwagę. O tym niedopatrzeniu w OpenSSL i GnuTLS było wiadomo mówi się od wielu lat. W OpenSSL problem został rozwiązany w gałęzi 1.1.1, a w GnuTLS pozostaje niesprawionej.

Jako obejście sugeruje się usunięcie z systemowego magazynu certyfikatu „AddTrust External CA Root” (na przykład usunięcie z /etc/ca-certificates.conf i /etc/ssl/certs, a następnie uruchomienie „update-ca-certificates -f -v”), po czym OpenSSL zaczyna poprawnie obsługiwać wzajemnie podpisane certyfikaty z jego udziałem. Korzystając z menedżera pakietów APT na własne ryzyko, można wyłączyć weryfikację certyfikatów dla pojedynczych żądań (na przykład „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false”).

Aby zablokować problem w Fedora i RHEL zaleca się dodanie certyfikatu AddTrust do czarnej listy:

zrzut zaufania — filtr «pkcs11:id=;typ=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Jednak ten sposób nie działa dla GnuTLS (na przykład nadal występuje błąd weryfikacji certyfikatu przy uruchamianiu narzędzia wget).

Po stronie serwera można zmienić kolejność wymieniania certyfikatów w łańcuchu zaufania, wysyłanych przez serwer do klienta (jeśli certyfikat związany z „AddTrust External CA Root” zostanie usunięty z listy, to weryfikacja przez klienta przebiegnie pomyślnie). Aby sprawdzić i wygenerować nowy łańcuch zaufania, można skorzystać z serwisu whatsmychaincert.com. Firma Sectigo również przekazała alternatywny wzajemnie podpisany certyfikat pośredni „AAA Certificate Services„, który będzie ważny do 2028 roku i pozwoli zachować kompatybilność ze starymi wersjami systemów operacyjnych.

Uzupełnienie: Problem także objawia się w LibreSSL.

Źródło: opennet.ru