Устараненне каранёвага сертыфіката AddTrust прывяло да збояў у сістэмах з OpenSSL і GnuTLS

30 мая скончыўся 20-гадовы тэрмін дзеяння каранёвага сертыфіката AddTrust, Які прымяняўся для фармавання перакрыжаванага подпісу (cross-signed) у сертыфікатах аднаго з найбуйных якія сведчаць цэнтраў Sectigo (Comodo). Скрыжаваны подпіс дазваляў забяспечыць сумяшчальнасць з састарэлымі прыладамі, у сховішча каранёвых сертыфікатаў якіх не быў дададзены новы каранёвы сертыфікат USERTRust.

Тэарэтычна спыненне дзеяння каранёвага сертыфіката AddTrust павінна было прывесці толькі да парушэння сумяшчальнасці з састарэлымі сістэмамі (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 і да т.п.), бо другі каранёвы сертыфікат, які выкарыстоўваецца ў крыжаваным подпісы застаецца сучасныя браўзэры ўлічваюць яго пры праверцы ланцужка даверу. На практыцы выявіліся праблемы з праверкай перакрыжаванага подпісу ў не выкарыстоўвалых браўзэры TLS-кліентах, у тым ліку на базе OpenSSL 1.0.x і GnuTLS. Бяспечнае злучэнне перастала ўсталёўвацца з высновай памылкі аб састарэнні сертыфіката, калі на серверы выкарыстоўваецца сертыфікат Sectigo, злучаны ланцужком даверу з каранёвым сертыфікатам AddTrust.

Калі карыстачы сучасных браўзэраў не заўважылі састарэння каранёвага сертыфіката AddTrust пры апрацоўцы крыжавана падпісаных сертыфікатаў Sectigo, то ў розных іншых прыкладаннях і серверных апрацоўшчыках пачалі ўсплываць праблемы, што прывяло да парушэння працы многіх інфраструктур, якія выкарыстоўваюць шыфраваныя каналы сувязі для ўзаемадзеяння паміж кампанентамі.

Напрыклад, узніклі праблемы з доступам да некаторых рэпазітараў пакетаў у Debian і Ubuntu (apt стаў выдаваць памылку праверкі сертыфіката), сталі завяршацца збоем звароту з скрыптоў пры дапамозе ўтыліт "curl" і "wget", назіраюцца памылкі пры выкарыстанні Git, парушылася праца платформы струменевага вяшчання Roku, перасталі выклікацца апрацоўшчыкі Паласа и DataDog, пачалі узнікаць крахі у дадатках Heroku, перасталі падлучацца кліенты OpenLDAP, фіксуюцца праблемы з адпраўкай пошты на серверы SMTPS і SMTP са STARTTLS. Акрамя таго назіраюцца праблемы ў розных Ruby-, PHP-і Python-скрыптах, якія выкарыстоўваюць модуль з http-кліентам. З браўзэраў праблема закранае Epiphany, у якім перасталі загружацца спісы блакіроўкі рэкламы.

Праграмы на мове Go праблеме не схільныя, бо ў Go прапануецца уласная рэалізацыя TLS.

Меркавалася, што праблема закранае старыя выпускі дыстрыбутываў (уключаючы Debian 9, Ubuntu 16.04, RHEL 6/7) у якіх выкарыстоўваюцца праблемныя галінкі OpenSSL, але праблема выявілася таксама пры працы пакетнага мэнэджара APT у актуальных выпусках Debian 10 і Ubuntu 18.04/20.04, бо APT выкарыстоўвае бібліятэку GnuTLS. Сутнасць праблемы ў тым, што многія TLS/SSL-бібліятэкі разбіраюць сертыфікат як лінейны ланцужок, у той час як у адпаведнасці з RFC 4158 сертыфікат можа прадстаўляць арыентаваны размеркаваны цыклічны граф з некалькімі якарамі даверу, якія трэба ўлічваць. Аб дадзенай недапрацоўцы ў OpenSSL і GnuTLS было вядома ўжо шмат гадоў. У OpenSSL праблема была ўхілена ў галінцы 1.1.1, а ў gnuTLS застаецца нявыпраўленай.

У якасці абыходнага шляху ўхілення збою прапануецца выдаліць з сістэмнага сховішча сертыфікат "AddTrust External CA Root" (напрыклад, выдаліць з /etc/ca-certificates.conf і /etc/ssl/certs, а затым запусціць "update-ca-certificates -f -v»), пасля чаго OpenSSL пачынае нармальна апрацоўваць перакрыжавана падпісаныя сертыфікаты з яго ўдзелам. Пры выкарыстанні пакетнага мэнэджара APT на свой страх і рызыку можна адключыць для асобных запытаў праверку сертыфікатаў (напрыклад, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false").

Для блакавання праблемы ў Мяккая фетравы капялюш и RHEL прапануецца дадаць сертыфікат AddTrust у чорны спіс:

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

Але гэты спосаб не працуе для GnuTLS (напрыклад, працягвае выдавацца памылка праверкі сертыфіката пры запуску ўтыліты wget).

На баку сервера можна змяніць парадак пералічэння сертыфікатаў у ланцужку даверу, якія адпраўляюцца серверам да кліента (калі звязаны з "AddTrust External CA Root" сертыфікат будзе прыбраны са спісу, то праверка кліентам пройдзе паспяхова). Для праверкі і генерацыі новага ланцужка даверу можна выкарыстоўваць сэрвіс whatsmychaincert.com. Кампанія Sectigo таксама прадаставіла альтэрнатыўны перакрыжавана падпісаны прамежкавы сертыфікатСертыфікацыйныя паслугі AAA«, Які будзе дзейнічаць да 2028 года і дазволіць захаваць сумяшчальнасць са старымі версіямі АС.

Дадатак: Праблема таксама праяўляецца у LibreSSL.

Крыніца: opennet.ru