I Server Parlano

// Questa Non e' una Scansione

Non ho inviato pacchetti malevoli. Non ho cercato vulnerabilita'. Non ho tentato accessi. Non ho usato exploit.

Ho fatto domande.

Le stesse domande che fa il tuo browser ogni volta che apri un sito. Le stesse che fa il tuo client email ogni volta che invia un messaggio. Le stesse che ogni server su Internet risponde migliaia di volte al giorno, a chiunque le faccia.

Query DNS. Ogni dominio ha record pubblici: chi gestisce la posta, chi firma i messaggi, che policy applica. Sono progettati per essere letti da chiunque. E' il modo in cui funziona Internet.

Richieste HTTP. Una HEAD request a un server web. La stessa cosa che fa Google quando indicizza una pagina. Il server risponde con i suoi header: che software usa, che protezioni ha, come gestisce la sicurezza.

Connessione TLS. Una connessione sulla porta 443 rivela la versione del protocollo, l'autorita' di certificazione, la scadenza e i nomi alternativi (SAN) registrati nel certificato.

// Metodo

// La Lista

Il punto di partenza e' IndicePA: il registro ufficiale degli enti pubblici italiani. Lo pubblica AgID, l'Agenzia per l'Italia Digitale. E' un dataset aperto, scaricabile, che contiene nome, indirizzo, contatti e dominio web di ogni ente della pubblica amministrazione.

Comuni. ASL. Regioni. Province. Universita'. Ministeri. Scuole. Agenzie. Ordini professionali. Consorzi. Aziende municipalizzate. Tutto.

Da quel dataset ho estratto i domini. Li ho puliti: rimossi i duplicati, gli invalidi, quelli che iniziano con un punto. Restano 22.313 domini unici. E' la mappa dell'infrastruttura digitale della PA italiana.

Poi ho scritto sei script. Richieste HTTP, query DNS, connessioni TLS, record email. Nient'altro. 1.200 righe di Python in tutto, qualche ora di runtime.

E i server hanno iniziato a parlare.

// Il Trasporto

La prima domanda e' la piu' semplice: il sito usa HTTPS?

HTTPS non e' un optional. E' il minimo. Significa che la comunicazione tra il browser del cittadino e il server dell'ente e' cifrata. Senza HTTPS, chiunque sulla stessa rete puo' leggere tutto: dati inseriti nei form, pagine visitate, documenti scaricati.

Il 18,4% dei domini PA non ha HTTPS funzionante. Sono 4.109 siti. Nel 2026.

Ma il numero piu' insidioso e' un altro: 5.315 domini non redirigono HTTP verso HTTPS. Significa che anche se il sito ha HTTPS, se un cittadino digita l'indirizzo senza "https://", la connessione resta in chiaro. Alcuni browser tentano l'upgrade automatico, ma il comportamento non e' garantito e dipende dal client. In molti casi il server non lo forza. Il traffico puo' viaggiare leggibile.

// TLS: cosa succede dopo l'HTTPS

HTTPS indica che una connessione e' cifrata. Ma non tutte le connessioni HTTPS sono uguali: la sicurezza reale dipende dalla versione del protocollo TLS e dal certificato utilizzato.

Ho negoziato una connessione TLS con ciascuno dei 22.313 domini.

Tre quarti dei domini che supportano HTTPS utilizzano TLS 1.3, la versione piu' recente del protocollo. Una quota piu' piccola utilizza ancora TLS 1.2 — che rimane comunque una versione sicura se configurata correttamente. Oltre il 10% dei domini non risponde affatto sulla porta 443.

Una nota: i 19.946 domini che negoziano TLS non coincidono con i 18.204 che nella sezione precedente risultano con "HTTPS funzionante". La differenza sono circa 1.700 domini che completano l'handshake TLS ma non restituiscono una risposta HTTP valida — certificati invalidi, configurazioni incomplete, server che accettano la connessione ma non servono contenuti. Il dato HTTPS misura l'esperienza utente; il dato TLS misura il protocollo.

// Chi firma i certificati

Piu' della meta' dei certificati utilizzati dalla PA italiana proviene da Let's Encrypt, la CA gratuita che ha reso l'HTTPS accessibile a chiunque.

Actalis, l'autorita' di certificazione italiana, mantiene una presenza significativa nei domini pubblici. Sectigo arriva quasi sempre dall'hosting provider. Google Trust Services e' in crescita — segno di infrastruttura che migra verso il cloud.

// Certificati problematici

1.011 domini presentano certificati TLS non validi: certificati scaduti, auto-firmati o configurati per un hostname diverso. Il browser mostra un avviso di sicurezza. L'utente deve cliccare "Procedi comunque" per accedere al sito di un ente pubblico.

Alcuni certificati risultano prossimi alla scadenza: 904 entro 30 giorni e 38 entro una settimana. Con Let's Encrypt — che emette certificati validi 90 giorni — il rinnovo automatico e' essenziale. Quando si rompe, il sito sparisce.

17 domini supportano ancora configurazioni Diffie-Hellman con chiavi deboli, associate alla vulnerabilita' Logjam (CVE-2015-4000). 76 domini hanno l'SNI mal configurato: il server non riconosce il proprio hostname durante l'handshake TLS.

// I certificati parlano

Ogni certificato TLS contiene un campo chiamato Subject Alternative Name (SAN). E' la lista di tutti i domini per cui quel certificato e' valido.

Quando un browser apre una connessione HTTPS, il server invia il certificato durante l'handshake TLS. Quella lista diventa pubblica. Basta leggerla.

Ho estratto i SAN da tutti i certificati TLS raggiungibili nei 22.313 domini della PA.

Da 22 mila domini emergono quasi 46 mila hostname. Un certificato TLS non rivela solo l'identita' di un dominio. Rivela l'ecosistema in cui vive.

Il dato piu' forte e' il primo: il 66,5% dei domini della PA condivide il certificato TLS con altri domini. Osservando il certificato di un singolo sito e' possibile scoprire decine di altri domini ospitati sulla stessa piattaforma.

Alcuni esempi: 55 comuni condividono lo stesso certificato TLS. ACI compare in 97 certificati di altri domini. intranet.regione.lombardia.it appare nel SAN di un certificato pubblico. comunestg.it (staging) compare in 31 certificati. demo.sviluppocalabria.info in 29.

Non sono vulnerabilita'. Sono informazioni che i server pubblicano automaticamente quando stabiliscono una connessione HTTPS.

// La Configurazione

Quando un browser chiede una pagina, il server risponde con degli header HTTP. Sono metadati invisibili all'utente ma fondamentali per la sicurezza. Dicono al browser come comportarsi: cosa puo' caricare, da dove, come gestire i frame, se forzare HTTPS.

Sono sei gli header di sicurezza standard:

6.273 siti PA non espongono nessuno dei sei header analizzati. Zero su sei. Il 34,5%. Piu' di un terzo dell'infrastruttura web della pubblica amministrazione italiana non dichiara alcun header di sicurezza standard.

Dall'altra parte, solo 1.657 domini li hanno tutti e sei. Il 9,1%.

// Il Fingerprint

Oltre ai security header, i server HTTP rispondono con altri campi. Due sono particolarmente interessanti per chi osserva: Server e X-Powered-By.

Il primo dice che software web gira sulla macchina. Il secondo dice che linguaggio o framework c'e' dietro. Nessuno dei due e' necessario. Sono informazioni che il server regala, gratuitamente, a chiunque faccia una richiesta.

Solo il 10% non dichiara nulla. Il restante 90% rivela il software web in uso — non sempre la versione, ma abbastanza per restringere il campo. Chi osserva il server non deve indovinare: basta leggere la risposta.

Ma il dato piu' preoccupante e' X-Powered-By. Il 40,5% dei domini dichiara la tecnologia e spesso la versione esatta:

906 domini PA usano versioni di PHP fuori supporto. Niente patch di sicurezza, niente aggiornamenti. 255 sono ancora su PHP 5, una versione il cui supporto e' terminato nel 2018. Alcuni sono su PHP 5.2, rilasciato nel 2006.

// L'Identita'

Questa e' la parte che fa piu' paura.

Funziona cosi': il protocollo email (SMTP) e' stato progettato negli anni '80. Non ha autenticazione nativa. Chiunque puo' inviare un'email con qualsiasi indirizzo mittente. Come spedire una lettera scrivendo l'indirizzo di qualcun altro sul retro della busta.

Per risolvere questo problema sono nati tre meccanismi, tutti basati su record DNS pubblici:

SPF (Sender Policy Framework) dice quali server sono autorizzati a inviare email per conto del dominio. Se ricevi un'email da @comune.esempio.it, il tuo server posta controlla il record SPF di comune.esempio.it per vedere se il server mittente e' nella lista.

DMARC (Domain-based Message Authentication) dice cosa fare quando un'email fallisce i controlli. Tre opzioni: none (non fare niente, solo monitora), quarantine (metti in spam), reject (rifiuta).

DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica a ogni email. La chiave pubblica sta nel DNS. Il ricevente la usa per verificare che il messaggio non sia stato alterato.

Ora, i numeri.

Leggiamoli.

Il 51,7% dei domini PA non ha DMARC. 11.529 domini. Nessuna istruzione su cosa fare con le email false. Il server ricevente decide da solo, e spesso decide di consegnarle.

Ma il dato piu' subdolo e' un altro: il 41,9% ha DMARC con policy p=none. 9.343 domini. DMARC viene spesso configurato inizialmente in modalita' di monitoraggio (p=none), per osservare il traffico prima di applicare restrizioni. Ma in molti casi questa fase non si conclude mai. E' come installare un antifurto e lasciarlo spento. Tecnicamente c'e'. Praticamente no.

Somma: il 93,6% dei domini PA non blocca le email falsificate. Tra chi non ha DMARC e chi ce l'ha ma non lo usa, solo il 3,1% ha p=reject. 683 domini su 22.313.

L'81% non ha DKIM. 18.067 domini senza firma crittografica sulle email. Nessun modo per il destinatario di verificare che il messaggio sia autentico e integro.

3.355 domini non hanno ne' SPF, ne' DMARC, ne' DKIM. Il 15% della PA italiana non ha alcun meccanismo di autenticazione email. Zero.

// I Fantasmi

C'e' un dato che non riguarda la sicurezza ma racconta qualcosa di piu' profondo.

1.580 domini registrati su IndicePA non risolvono il DNS. Sono nel registro ufficiale della PA ma non esistono piu'. Il server e' spento, il dominio e' scaduto, l'ente e' stato accorpato. Ma la riga nel database c'e' ancora.

E poi ci sono i 813 che vanno in timeout. Il DNS risolve, punta a un indirizzo IP, ma nessuno risponde. Un server configurato, un IP assegnato, ma nessun servizio attivo.

Insieme fanno quasi 2.400 domini: il 10,7% del registro ufficiale punta al vuoto.

// La Firma

Un ultimo dato. Semplice, elegante, devastante.

DNSSEC e' un'estensione del protocollo DNS che aggiunge una firma crittografica alle risposte. Serve a garantire che quando chiedi "dove si trova comune.esempio.it", la risposta che ricevi sia autentica e non sia stata manipolata. Senza DNSSEC, tecniche come il cache poisoning o il man-in-the-middle possono alterare le risposte DNS senza che il client possa verificarne l'autenticita'.

295 domini su 22.313 hanno DNSSEC. L'1,3%.

Non e' sorprendente. DNSSEC e' complesso da implementare e gestire. Ma e' una misura della maturita' infrastrutturale: quanti enti hanno investito nella sicurezza del livello piu' basso dello stack, quello su cui tutto il resto si appoggia.

La risposta e': quasi nessuno.

// La Mappa

Ho costruito un indice sintetico: il PA Exposure Score. Scala da 0 a 10, dove 10 significa massima esposizione. Pesa quattro fattori: trasporto (HTTPS), configurazione web (header), fingerprinting (server disclosure) e identita' email (SPF/DMARC).

La media nazionale e' 5,51 su 10.

Le piu' esposte: Molise (6,30), Campania (5,97), Calabria (5,96). Le piu' protette: Trentino-Alto Adige (4,19), Veneto (4,86), Valle d'Aosta (5,14).

Il divario nord-sud c'e', ma non e' l'unica storia. Il Piemonte (5,79) sta peggio della Sardegna (5,41). La Liguria (5,91) sta peggio della Sicilia (5,77). La dimensione dell'ente e la categoria contano piu' della latitudine.

Ho messo anche il Molise, anche se molti di voi diranno che il Molise non esiste.

// I Tipi

Non tutti gli enti sono uguali. La postura di sicurezza cambia radicalmente in base alla categoria.

Due numeri saltano fuori.

Le scuole sono spoofabili al 97,6%. 8.022 domini, quasi tutti con email falsificabile. Solo lo 0,6% ha DMARC reject. E' la categoria piu' esposta in assoluto: chiunque puo' mandare un'email che sembra provenire da una scuola pubblica italiana.

Le ASL hanno il peggior HTTPS (57,9%) ma il miglior DMARC reject (13,2%). Paradosso: l'ente che gestisce i dati sanitari dei cittadini e' quello che meno protegge il trasporto web, ma quello che piu' protegge l'identita' email. Probabilmente perche' la sanita' e' stata bersaglio di attacchi phishing mirati e ha reagito.

// Dove Vivono Questi Domini

Ogni dominio ha un nameserver. Chi risponde alle query DNS, chi traduce il nome in indirizzo IP. Una riga nel record NS che racconta dove vive un sito prima ancora di aprirlo.

Ho estratto i nameserver di tutti i 22.313 domini. Il risultato e' una mappa di concentrazione.

Quasi un terzo della pubblica amministrazione italiana vive su Aruba. Un singolo provider. Se un provider DNS ha un problema operativo, migliaia di domini possono essere impattati contemporaneamente. Non e' un'ipotesi: e' gia' successo.

Il 61.4% dei domini usa provider italiani. Solo il 4.4% usa provider internazionali (Cloudflare, AWS, Azure, Google Cloud). Il resto e' un arcipelago di 846 provider diversi — piccoli hosting locali, server autogestiti, infrastruttura regionale.

// Stessi nameserver, stessa sorte

Non e' solo lo stesso provider. Sono gli stessi identici nameserver.

Ho confrontato le combinazioni NS esatte di tutti i 20.969 domini che hanno un record NS. Il risultato: 2.358 combinazioni uniche. Ma la distribuzione e' estrema.

Cinque combinazioni NS coprono il 55% dei domini. Il 71.6% dei domini con NS e' in cluster da 100 o piu' — stessa configurazione, stessa infrastruttura, stesso destino in caso di problemi.

Quei nameserver sono ridondati e distribuiti — non e' un single point of failure in senso tecnico. Ma e' una monocultura infrastrutturale. 6.587 domini condividono la stessa piattaforma, le stesse policy di routing, lo stesso software, gli stessi aggiornamenti. Un bug nella gestione DNS di Aruba, un errore di propagazione, un attacco mirato al loro AS — e migliaia di enti si muovono insieme, nella stessa direzione, nello stesso momento.

Alcuni cluster regionali sono ancora piu' stretti:

• Friuli Venezia Giulia — 223 domini su dns.insiel.net + dns.regione.fvg.it. Due NS, un'unica infrastruttura regionale.
• Trentino — 158 domini su dns1-7.infotn.it. Tutta la PA provinciale su un operatore.
• Basilicata — 114 domini su ns.basilicatanet.it + ns.regione.basilicata.it. L'intera regione.
• Emilia-Romagna — 148 domini su dns1-2.lepida.it. La rete regionale.
• Valle d'Aosta — 114 domini su ns1-2.invallee.it. Tutti.

// La geografia dei nameserver

Analizzando la geografia dei nameserver emerge un altro dato interessante. 10.550 domini della PA italiana utilizzano nameserver distribuiti in paesi diversi. Circa la meta' del totale.

Questa distribuzione geografica non e' necessariamente un problema: molti provider DNS utilizzano infrastrutture globali e tecniche come anycast per migliorare resilienza e prestazioni.

Il caso piu' diffuso e' quello dei domini ospitati sull'infrastruttura Aruba/Technorail, dove i nameserver includono nodi globali (technorail.com) insieme a server nel dominio arubadns.cz, localizzati in Repubblica Ceca. Un altro gruppo significativo e' rappresentato dai domini gestiti tramite Amazon Route 53, con nameserver distribuiti tra Stati Uniti e Regno Unito (awsdns-xx.co.uk).

Anche quando il dominio appartiene a un ente locale italiano, la sua infrastruttura DNS puo' essere distribuita su server situati in diversi paesi. Questo riflette la natura globale delle infrastrutture Internet: anche i servizi digitali della pubblica amministrazione si appoggiano spesso a piattaforme DNS distribuite a livello internazionale.

La gestione dei nomi su Internet raramente coincide con i confini amministrativi degli enti che li utilizzano.

// I domini fantasma

E poi ci sono i 1.344 domini senza nameserver. Nessun record NS. Non sono offline: sono senza delega DNS valida. Enti che risultano nell'indice della PA con un dominio che il DNS non sa risolvere — delega rotta, dominio scaduto o mai configurato.

Chi sono? Soprattutto scuole e ordini professionali.

Le regioni con piu' domini fantasma: Sicilia (182), Campania (177), Lazio (114). C'e' un Commissario Straordinario il cui dominio punta nel vuoto. Ci sono istituti alberghieri con il .edu.it che non risolve. Ordini professionali con domini .wordpress.com che non esistono piu'.

Non e' un problema tecnico. E' un problema di governance. Questi enti sono nell'indice ufficiale della PA italiana con un indirizzo web che non porta da nessuna parte. E nessuno se ne accorge.

// Il TTL: il tempo di reazione dell'infrastruttura

Ogni record DNS ha un parametro chiamato TTL (Time To Live). Indica per quanto tempo una risposta DNS puo' essere memorizzata nella cache prima di essere richiesta di nuovo.

In pratica, il TTL misura quanto velocemente un cambio di indirizzo diventa visibile ai resolver.

Ho interrogato il record A di tutti i 22.313 domini. 20.753 hanno restituito un record A valido (il numero e' superiore ai domini con HTTP funzionante perche' un dominio puo' avere un record DNS valido anche se il server web non risponde o non serve contenuti HTTP). La mediana e' 3.600 secondi — un'ora esatta. E' il valore di default della maggior parte degli hosting. Il 37.1% dei domini usa esattamente questo valore.

Agli estremi si trovano le storie piu' interessanti.

680 domini hanno un TTL di 10 secondi. Infrastruttura dinamica, pronta a cambiare destinazione quasi in tempo reale. Tipico di servizi dietro CDN o load balancer distribuiti.

Sogei — l'infrastruttura tecnologica del Ministero dell'Economia — usa un TTL di 2 secondi. Con un TTL cosi' basso, un eventuale cambio di destinazione diventa visibile ai resolver in pochi secondi. E' un'infrastruttura critica configurata per reagire.

All'estremo opposto, tutti i domini dei comuni del Trentino condividono un TTL di sette giorni. Significa che una volta risolto l'indirizzo IP, i resolver possono mantenerlo in cache per un'intera settimana prima di chiedere di nuovo. E' una configurazione pensata per stabilita', piu' che per cambiamenti rapidi.

Il TTL non e' un parametro di sicurezza, ma racconta qualcosa di molto concreto: quanto velocemente un'infrastruttura puo' reagire.

// DNS avanzato: email e certificati

I record MX indicano quali server gestiscono la posta di un dominio. Anche qui i dati raccontano come e' distribuita l'infrastruttura.

Oltre la meta' dei domini della PA gestisce la posta su server propri, mentre circa un terzo utilizza piattaforme cloud come Google Workspace o Microsoft 365. L'8.5% dei domini non ha alcun record MX configurato, segno che quei domini non gestiscono posta elettronica o utilizzano indirizzi esterni.

I record SPF rivelano la stessa distribuzione vista dai MX. Le infrastrutture piu' presenti negli include: SPF sono Google (3.155 domini), Aruba (3.066 + 1.542) e Microsoft (2.734). 13 domini utilizzano la direttiva +all, che autorizza qualsiasi server a inviare email per conto del dominio. 31 usano il meccanismo ptr, deprecato da RFC 7208. La maggior parte dei domini utilizza ~all (soft fail), che segnala server non autorizzati ma lascia al destinatario la decisione finale.

Il record CAA permette a un dominio di specificare quali autorita' di certificazione sono autorizzate a emettere certificati TLS. Il 99% dei domini non definisce restrizioni esplicite su quali CA possano emettere certificati. Tra i 223 che lo fanno, Let's Encrypt e' l'autorita' piu' frequentemente autorizzata (191), seguita da Comodo (104) e DigiCert (95).

Infine, i record wildcard: 1.300 domini (5.8%) hanno un record *.dominio.it che fa si' che qualsiasi sottodominio non definito esplicitamente venga risolto automaticamente. In alcuni casi un singolo record wildcard serve numerosi sottodomini, configurazione tipica dell'hosting condiviso.

// Misurare la Superficie

Fin qui abbiamo contato. Ora misuriamo.

// Concentrazione: l'indice HHI

La concentrazione di un mercato si misura con l'indice di Herfindahl-Hirschman: la somma dei quadrati delle quote di mercato.

Un HHI sotto 1.500 indica un mercato competitivo; sopra 2.500, altamente concentrato. Per i provider DNS della PA italiana:

Il valore si colloca nella fascia competitiva. Ma il numero puro nasconde la realta': la distribuzione e' fortemente asimmetrica. Per misurarla serve un altro strumento.

// Diversita': l'entropia di Shannon

L'entropia di Shannon misura la diversita' reale di un sistema:

Se tutti i provider fossero uguali, l'entropia sarebbe massima: \(\log_2(846) = 9{,}72\) bit. Il valore misurato e':

Convertendo in numero effettivo di provider — una misura usata in ecologia per la biodiversita' e in economia per la concentrazione:

L'infrastruttura della PA usa 846 provider, ma la sua diversita' reale equivale a 39. In altre parole: molti provider esistono, ma pochi contano davvero.

// Information leakage: i bit esposti

Ogni risposta di un server pubblico rivela informazione. Quanta? Si puo' misurare in bit — la stessa unita' con cui si misura l'entropia.

Una singola richiesta HTTP e una query DNS rivelano circa 20 bit di informazione sull'infrastruttura di un server della PA. Abbastanza per distinguere un dominio tra un milione di configurazioni possibili.

// Cosa Significa

Non ho scansionato nulla. Ho solo ascoltato.

DNS, header HTTP, record email. Protocolli pubblici, risposte automatiche, dati che ogni server offre a chiunque li chieda. Un portatile, sei script Python, 1.200 righe di codice.

E quello che emerge e' una fotografia:

Internet e' progettata per essere osservabile.

Il problema non e' la vulnerabilita' singola. Il problema e' la superficie. Ventiduemila domini che rispondono a chiunque, la maggior parte senza protezioni di base, molti con software obsoleto, quasi tutti con un'identita' email falsificabile.

Senza effettuare alcuna scansione attiva, l'analisi di dati pubblici rivela una superficie digitale vasta e spesso poco protetta: configurazioni web minime, infrastrutture facilmente identificabili e un sistema email che nella maggior parte dei casi puo' essere falsificato.

E tutto questo e' visibile a chiunque sappia dove guardare. O meglio: a chiunque sappia ascoltare.