Il certificato dietro il lucchetto aveva gia' annunciato la pagina che non avevi ancora lanciato

Un concorrente apre la stessa identica citta' una settimana dopo che il team ha finito di testarla in silenzio, prima ancora che venga comprato un annuncio o pubblicato un link. Un operatore scopre, da uno sconosciuto in un forum, che qualcuno ha curiosato su una pagina di accesso che fuori dall'azienda nessuno avrebbe dovuto sapere che esisteva. Nessuno dei due casi somiglia a una fuga di notizie da un dipendente, a una casella email violata o a un colpo di fortuna. Entrambi di solito si spiegano con qualcosa di molto piu' banale: un certificato di sicurezza, emesso in automatico, che fa esattamente quello per cui e' stato progettato.

Il meccanismo si chiama Certificate Transparency e non ha nulla a che vedere con un attacco informatico. E' un registro pubblico e permanente dei certificati HTTPS che esiste dal 2018, consultabile gratuitamente, e contiene gia' la storia completa di ogni nome host che questo sito, o qualsiasi altro sito, ha messo dietro a un certificato funzionante senza avviso del browser. Quasi nessun operatore ha mai controllato la propria voce in quel registro. Questo e' il vero vuoto da colmare qui: non una falla nel senso abituale, ma un registro che e' sempre stato pubblico e non e' mai stato trattato come tale.

Cosa diventa in silenzio un certificato, nel momento in cui viene emesso

Dal 2018, un certificato di fiducia pubblica, quello che fa comparire su Chrome e Safari un semplice lucchetto invece di un avviso, deve essere registrato in uno dei diversi log di Certificate Transparency, altrimenti quei browser non lo accettano. Apple ha introdotto lo stesso obbligo su Safari piu' tardi, nello stesso anno. Non era pensato per i siti per adulti o per le directory di annunci in particolare: serviva a impedire che qualcuno emettesse di nascosto un certificato falso per il dominio di qualcun altro e ne intercettasse il traffico. L'effetto collaterale e' che il log registra anche ogni certificato vero che un sito ottiene per se stesso, e quel registro non e' mai stato pensato per restare privato.

Il log elenca, per nome, ogni host effettivamente coperto da un certificato. Un certificato emesso per admin.esempio.com riporta esattamente quel nome, in chiaro, per sempre. Non conta se la pagina dietro quel nome sia mai stata linkata dal menu del sito, citata in una mappa del sito o indicizzata da un motore di ricerca. L'autorita' di certificazione lo ha registrato nell'istante stesso in cui lo ha emesso, che si trattasse di Let's Encrypt, di Cloudflare o del gestore automatico di certificati integrato nella maggior parte dei pannelli di hosting, perche' tutti rispondono alle stesse regole dei browser.

Verificarlo non costa nulla e richiede meno di un minuto. Uno strumento gratuito chiamato crt.sh permette a chiunque di digitare un dominio e vedere ogni certificato mai registrato per quel nome, senza account, senza iscrizione. Digitare il dominio di un concorrente funziona esattamente come digitare il proprio, ed e' proprio questo a trasformare un registro tecnico di routine in un rischio per l'azienda. Chiunque legga queste righe puo' aprire quella pagina adesso e vedere, per la prima volta, cosa il proprio dominio ha gia' raccontato al mondo.

C'e' un'eccezione reale, e conta per tutto quello che segue: un certificato wildcard, quello che copre un intero schema come *.esempio.com invece di un nome esatto, registra nel log solo quello schema. I nomi host specifici che lo usano davvero, nuovacitta.esempio.com o staging.esempio.com, non compaiono per nome nel registro. Un certificato dedicato a un singolo sottodominio esatto, invece, compare sempre per nome. Questa differenza e' la leva concreta che un operatore ha davvero a disposizione, e torna piu' avanti.

Cosa consegna davvero a uno sconosciuto, in tre modi concreti

Il primo e' il tempismo su un'espansione. Una nuova pagina di citta' o di paese viene quasi sempre costruita e testata sul proprio sottodominio giorni o settimane prima che il marketing sia pronto ad annunciarla, e testarla via HTTPS significa che il relativo certificato viene emesso proprio durante quel periodo silenzioso, non il giorno del lancio. Esistono strumenti di monitoraggio gratuiti, costruiti sullo stesso log pubblico, che avvisano chi li usa entro pochi minuti o poche ore ogni volta che compare un nuovo certificato per un dominio sotto osservazione. Un concorrente che gia' conosce il dominio principale, pubblico per definizione, non deve indovinare il nome della nuova citta': gli basta tenerlo d'occhio, e il registro glielo consegna prima ancora che esca l'annuncio.

Il secondo e' la mappa degli strumenti interni. Una directory di queste dimensioni gestisce di solito una pagina di accesso per lo staff, una coda per chi rivede gli annunci, magari un pannello separato per un fornitore esterno dei pagamenti. Se ognuno di questi ha ottenuto un proprio certificato con un nome descrittivo, admin, moderazione, fatturazione, il log si legge ormai come una piantina dell'edificio. Quella piantina e' esattamente il punto di partenza dietro il tipo di intrusione gia' trattato qui, dove il modo abituale di entrare non e' un exploit spettacolare ma una password riciclata provata contro qualunque pagina di accesso fosse piu' facile da trovare. Un sottodominio con nome descrittivo non causa da solo quell'intrusione, ma toglie il primo passo, trovare la pagina di accesso, che altrimenti avrebbe rallentato chi attacca.

Il terzo e' una storia che nessuno puo' cancellare. Il log non dimentica. Un sottodominio di prova di tre anni fa, una pagina nata per un partner che non esiste piu', una copia di staging che uno sviluppatore intendeva eliminare e si e' dimenticato: tutto resta nel registro per sempre, anche dopo che il certificato scade, anche dopo che il record DNS che vi puntava viene rimosso. Cercare oggi un dominio su crt.sh puo' far emergere nomi che nessuno del team attuale ricorda di aver creato. La parte pericolosa non e' la voce in se', ma la possibilita' che il server che rispondeva a quell'indirizzo sia ancora li', mai aggiornato, perche' tutti hanno dato per scontato che togliere il link equivalesse a spegnerlo.

Niente di tutto questo richiede competenze che la maggior parte delle persone chiamerebbe hacking. Serve solo sapere che esiste una casella di ricerca gratuita e digitarci dentro un nome a dominio, ed e' proprio per questo che vale la pena prenderlo sul serio invece di archiviarlo tra i problemi di sicurezza di cui si occupa qualcun altro.

Cosa non ferma niente di tutto questo, e cosa invece funziona davvero

Viene naturale affidarsi agli stessi strumenti usati per gestire come i motori di ricerca vedono un sito, ma qui non si applicano. Le scelte che questa directory fa gia' su quali crawler possono vedere quali pagine passano dal file robots.txt e dall'indicizzazione dei motori di ricerca, un sistema completamente diverso di cui un log di certificati non ha mai sentito parlare. Bloccare un bot, deindicizzare una pagina o segnarla come noindex non cambia nulla sul fatto che il suo certificato compaia nel registro, perche' il registro annota il certificato in se', non la visibilita' della pagina sui motori di ricerca.

Non esiste nemmeno un modo legittimo per ottenere un certificato che funzioni senza avviso nel browser di un visitatore e tenerlo fuori dal registro. Chiedere a un provider di hosting o a un'autorita' di certificazione di fare un'eccezione significa chiedere qualcosa che per un'attivita' rivolta al pubblico non esiste: gli unici certificati esenti dalla registrazione sono quelli emessi da un'autorita' di certificazione privata e interna, che i browser dei visitatori comuni non riconoscono affatto, il che li rende inutili per qualunque cosa un cliente o un inserzionista debba davvero aprire.

Anche rinominare o eliminare un sottodominio in un secondo momento non risolve nulla, perche' la vecchia voce nel registro resta esattamente dov'era. Non esiste alcuna pulizia retroattiva per un nome gia' registrato in questo modo: l'unica cosa che un operatore puo' davvero cambiare e' cosa succede da qui in avanti.

Cio' che funziona davvero e' il certificato wildcard descritto sopra, usato in modo deliberato. Gli strumenti interni, le copie di staging e tutto cio' che viene testato prima di un lancio pubblico dovrebbero stare dietro un unico certificato che copre uno schema intero, invece di un certificato nuovo emesso per nome ogni volta. La maggior parte dei pannelli di hosting e delle reti di distribuzione dei contenuti emette per impostazione predefinita un certificato con nome proprio nel momento stesso in cui si aggiunge un nuovo sottodominio, perche' quella impostazione e' piu' semplice da costruire, non perche' sia la scelta piu' sicura; chiedere all'host o allo sviluppatore di cambiare proprio quell'impostazione per tutto cio' che non e' una pagina di marketing pubblica e' una domanda concreta e verificabile, non una generica richiesta di migliorare la sicurezza.

La seconda correzione reale e' smettere di affidarsi a un nome oscuro come se fosse una serratura. Una pagina di accesso, una coda di moderazione o un pannello di fatturazione hanno bisogno di una vera verifica tramite password e, dove possibile, di una restrizione a un insieme noto di indirizzi dell'ufficio o dello staff, qualunque sia il loro nome, perche' il nome non e' mai stato l'unico modo per trovarli: esistono altri metodi tecnici per far emergere i sottodomini di un sito che non hanno nulla a che fare con i certificati. Trattare un nome difficile da indovinare come la difesa principale e' l'errore vero, non la scelta del certificato in se'. La scelta del certificato decide solo se quel nome viene regalato gratis prima ancora che qualcuno debba cercarlo.

Cosa controllare davvero questa settimana

Il primo passo non costa nulla e richiede cinque minuti: aprire crt.sh, digitare il dominio di questo sito e leggere l'elenco completo di tutto cio' che compare. Qualunque voce non riconosciuta merita una domanda diretta a chi gestisce l'hosting: funziona ancora, e se si', perche' oggi l'internet pubblico conosce il suo indirizzo.

Per tutto cio' che in quell'elenco risulta essere una funzione abbandonata, un test concluso o un progetto per un partner che non c'e' piu', la correzione non e' limitarsi a togliere il record DNS. Qualunque cosa stesse dietro quell'indirizzo andrebbe spenta a livello di server, con la conferma che non risponda piu' ad alcuna richiesta, invece di lasciarla funzionare in silenzio togliendo solo il cartello che vi puntava.

Per il prossimo lancio di una nuova citta' o di un nuovo paese, la fase di test dovrebbe girare sotto un certificato wildcard o uno condiviso a uso interno, invece che sotto un certificato emesso per nome specifico di quella citta', cosi' che il registro non annunci l'espansione prima del marketing. E' un'impostazione singola da confermare con uno sviluppatore o un provider di hosting prima del prossimo lancio, non la ricostruzione di qualcosa gia' attivo.

Per ogni pagina interna di accesso, moderazione o fatturazione gia' attiva oggi, la domanda non e' se il suo nome sia difficile da indovinare. E' se davanti ci sia una vera password e, dove possibile, una restrizione per indirizzo, a prescindere dal nome, perche' e' quella la parte che regge davvero una volta che il nome stesso e' gia' pubblico, cosa che, dopo aver controllato crt.sh, molto probabilmente e' gia' vera.