L'obsolescenza del certificato radice AddTrust ha portato a malfunzionamenti nei sistemi con OpenSSL e GnuTLS

Il 30 maggio è scaduto il termine di 20 anni per la validità del certificato radice AddTrust, che veniva utilizzato per la creazione di una firma incrociata (cross-signed) nei certificati di uno dei più grandi enti certificatori, Sectigo (Comodo). La firma incrociata consentiva di garantire la compatibilità con i dispositivi obsoleti, i cui magazzini di certificati radice non avevano ricevuto il nuovo certificato radice USERTrust.

Teoricamente, la scadenza del certificato radice AddTrust avrebbe dovuto comportare solo la perdita di compatibilità con sistemi obsoleti (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, ecc.), poiché il secondo certificato radice, utilizzato nella firma incrociata, rimane valido e i browser moderni lo considerano nella verifica della catena di fiducia. In pratica sono emerse problematiche durante la verifica della firma incrociata nei client TLS che non utilizzano i browser, tra cui quelli basati su OpenSSL 1.0.x e GnuTLS. La connessione sicura ha smesso di essere stabilita con un messaggio di errore riguardo la scadenza del certificato, se sul server viene utilizzato un certificato Sectigo, collegato tramite catena di fiducia al certificato radice AddTrust.

Se gli utenti dei browser moderni non hanno notato la scadenza del certificato radice AddTrust durante l'elaborazione dei certificati firmati in modo incrociato da Sectigo, vari applicativi di terze parti e gestori server hanno iniziato a mostrare problemi, portando a a malfunzionamenti interruzioni del funzionamento di molte infrastrutture che utilizzano canali di comunicazione crittografati per l'interazione tra i componenti.

Ad esempio, si sono verificati problemi problemi con l'accesso ad alcuni repository di pacchetti in Debian e Ubuntu (apt ha iniziato a restituire errori di verifica del certificato), si sono conclusi con errori le chiamate dagli script utilizzando gli strumenti «curl» e «wget», si sono riscontrati errori nell'uso di Git, è stata compromessa la funzionalità della piattaforma di streaming Roku, hanno smesso di attivarsi i gestori Stripe e DataDog, sono iniziati i crash nelle applicazioni Heroku, non si sono collegati i client OpenLDAP, si sono riscontrati problemi nell'invio di email ai server SMTPS e SMTP con STARTTLS. Inoltre, si evidenziano problemi in vari script Ruby, PHP e Python che utilizzano moduli con client http. Tra i browser, il problema i processori AMD, per i quali non si manifesta il vettore di attacco principale. I metodi di mitigazione già implementati contro le vulnerabilità Spectre e Meltdown non proteggono dall'attacco SWAPGS utilizzando processori Intel, ma sono già state proposte delle patch per Linux, ChromeOS, Android e Windows. Epiphany, in cui non si caricano più le liste di blocco della pubblicità.

I programmi scritti in Go non sono soggetti al problema, poiché in Go viene fornita una propria implementazione di TLS.

Si presume, il problema riguarda le vecchie versioni dei pacchetti (inclusi Debian 9, Ubuntu 16.04, RHEL 6/7) in cui sono presenti le ramificazioni problematiche di OpenSSL, ma il problema si è manifestato anche durante l'utilizzo del gestore di pacchetti APT nelle versioni attuali di Debian 10 e Ubuntu 18.04/20.04, poiché APT utilizza la libreria GnuTLS. Il punto cruciale del problema è che molte librerie TLS/SSL interpretano il certificato come una catena lineare, mentre secondo l'RFC 4158 un certificato può rappresentare un grafo ciclico diretto distribuito con diversi ancoraggi di fiducia che devono essere presi in considerazione. Questa mancanza in OpenSSL e GnuTLS era reso noto è nota da molti anni. In OpenSSL il problema è stato risolto nel ramo 1.1.1, mentre in GnuTLS rimane non risolto.

Come soluzione alternativa per risolvere il malfunzionamento, si consiglia di rimuovere dal keystore di sistema il certificato "AddTrust External CA Root" (ad esempio, rimuovendo da /etc/ca-certificates.conf e /etc/ssl/certs, quindi eseguendo "update-ca-certificates -f -v"), dopo di che OpenSSL inizia a gestire correttamente i certificati firmati incrociati che lo coinvolgono. Utilizzando il gestore di pacchetti APT a proprio rischio, è possibile disabilitare il controllo dei certificati per singoli comandi (ad esempio, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false").

Per bloccare il problema in Fedora e RHEL si consiglia di inserire il certificato AddTrust nella blacklist:

dump di fiducia —filtra «pkcs11:id=;type=cert»
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Ma questo metodo non funzioni per GnuTLS (ad esempio, continua a mostrare un errore di verifica del certificato quando si utilizza l'utility wget).

Sul lato del server è possibile modificare l'ordine dell'elenco dei certificati nella catena di fiducia, inviati dal server al cliente (se il certificato associato a "AddTrust External CA Root" viene rimosso dall'elenco, la verifica da parte del cliente andrà a buon fine). Per verificare e generare una nuova catena di fiducia, è possibile utilizzare il servizio whatsmychaincert.com. Anche Sectigo ha fornito un certificato intermedio firmato incrociato alternativo "AAA Certificate Services", che sarà valido fino al 2028 e consentirà di mantenere la compatibilità con le vecchie versioni del sistema operativo.

Nota: Il problema è presente anche si manifesta in LibreSSL.

Fonte: opennet.ru