Perché se tutti sono convinti che usare SSL/TLS sia sicuro, molti ancora disabilitano il controllo dei certificati?

All’interno di quel bacino pregno di pubblicazioni interessanti che è il blog di Daniel Stenberg, creatore e manutentore del progetto curl, è recentemente apparso un articolo che ogni manager, sviluppatore e DevSecOps dovrebbe leggere a proposito di come oggi, anno del Signore 2025, ci siano ancora parecchi progetti che non effettuano il controllo di validità dei certificati a cui si connettono.

Il controllo di validità è presente di default in curl sin dal 2002 e, come spiega l’articolo, è alla base di una serie di controlli impliciti che tutelano da tutte le forme più banali di attacco effettuato mediante HTTP. Ecco riassunta la lista:

• Se si prova ad usare il certificato del sito di produzione nell’ambiente di sviluppo, ci si può connettere al server usando un nome diverso e quindi la verifica fallisce.
• Se si ha un intermediario attivo che intercetta e vuole spiare il traffico TLS, quest’ultimo deve fornire un certificato diverso e, a meno che non possa essere firmato da una CA attendibile, la verifica fallisce.
• Se si ha un archivio CA obsoleto o non se ne ha uno, la verifica fallisce.
• Se il server non aggiorna correttamente il suo certificato, questo potrebbe scadere e quindi la verifica fallirebbe.
• Se l’orologio del client non è almeno approssimativamente sincronizzato con l’orario corretto, la verifica potrebbe fallire.

In coda all’elenco, anche se sarebbe inutile aggiungerlo, la documentazione di curl e libcurl scoraggia fortemente gli utenti dal disabilitare il controllo.

Insomma, è oggettivo come verificare il certificato protegga automaticamente da un numero enorme di problemi e potenziali attacchi.

Eppure.

Ecco un banalissimo controllo eseguito dallo stesso Stenberg, il quale è andato a cercare in GitHub l’impostazione CURLOPT_SSL_VERIFYPEER, FALSE – che per l’appunto consente di disabilitare la verifica del certificato del server a cui ci si sta collegando (usando libcurl) – trovando un numero di repository vicino ai 140.000!

Un’altra verifica, per il valore CURLOPT_SSL_VERIFYPEER, 0 ne ha rilevati 153.000.

Insomma, una strage che si accompagna anche a CVE piuttosto gravi di altri programmi che hanno queste impostazioni.

C’è una soluzione a tutto questo? Si arriverà mai ad avere una consapevolezza da parte degli operatori del settore sull’importanza del tema?

Intanto continuiamo a ripeterlo, male non fa.