Come previsto dal Piano Triennale per l’informatica nella Pubblica Amministrazione, AgID ha effettuato una nuova rilevazione sull’utilizzo del protocollo HTTPS e l’aggiornamento dei CMS nei sistemi della Pubblica Amministrazione.

A quasi un anno dalla pubblicazione del primo monitoraggio sull’utilizzo del protocollo HTTPS e sull’aggiornamento dei CMS nei portali della Pubblica Amministrazione, i dati rilevati dal CERT-AGID dopo la seconda rilevazione, effettuata tramite una serie di tools sviluppati internamente dagli analisti del CERT-AgID appaiono contrastanti.

Se da un lato la percentuale di siti che utilizza una corretta configurazione HTTPS è più che raddoppiata, dall’altro la percentuale dei CMS aggiornati evidenzia una lieve regressione.

Il miglioramento sul fronte dell’utilizzo di HTTPS non ha però riguardato quella percentuale di portali amministrativi che più ne aveva bisogno, ovvero tutti quei server che erano, e sono rimasti, privi di HTTPS.

La percentuale di siti che non supporta HTTPS è infatti rimasta invariata, rendendo meno soddisfacenti i progressi ottenuti.

Come è stata condotta questa rilevazione

• Metodologia
• Il delicato compito di misurare HTTPS
• La spinosa questione degli aggiornamenti CMS
• Come sono cambiati i dati in questi 10 mesi di intervallo
• Panoramica sull’utilizzo del protocollo HTTPS
• Panoramica sullo scenario dei CMS
• Conclusioni

Metodologia

Prima di analizzare come è variato lo scenario in questi 10 mesi trascorsi dalla prima rilevazione, è opportuno far luce sulla metodologia usata.

CERT-AGID si è basato sull’elenco dei siti della Pubblica Amministrazione disponibile nell’Indice PA (IPA). Evidenziamo che questo database non contiene ancora tutti i siti della PA per vari motivi: citiamo tra gli altri l’accreditamento allo stesso su base volontaria e la possibilità, al momento, per le Amministrazioni di censire solo l’indirizzo del loro portale primario. Delle 23.022 Amministrazioni al momento presenti nell’Indice, solo 21.839 hanno il campo sito_istituzionale valorizzato correttamente.

In sostanza, l’obiettivo che ci si è posto è stato quello di verificare, sui siti con dati validi su IPA, l’utilizzo del protocollo HTTPS e la presenza di CMS non aggiornati.
Entrambi questi obiettivi sono potenzialmente discutibili sul piano tecnico: verificare la presenza di HTTPS può essere fatto banalmente verificando se la porta 443 di un server è aperta o meno.

Ma quanto valore ha questo tipo di verifica? Possiamo dire che un server che utilizza HTTPS con un certificato non valido e poi dormire sonni tranquilli?

Gli analisti del CERT-AGID non hanno seguito questo tipo di approccio bensì hanno deciso di compiere uno sforzo maggiore per ottenere dati più significativi. Sul lato CMS poi, la faccenda, come vedremo in seguito, è risultata ancora più spinosa.

Il delicato compito di misurare HTTPS

HTTPS è un protocollo con una storia quasi trentennale, fatta anche da tante patch utilizzate per risolvere i suoi problemi di sicurezza e di upgrade per migliorarne l’efficienza.
Cercare di verificare se l’implementazione HTTPS di un server è sicura è un compito delicato e articolato: si deve verificare che non siano presenti certe configurazioni e che ve ne siano presenti altre ma… nè SSL nè TLS, i due protocolli alla base di HTTPS, supportano la semplice enumerazione delle configurazioni (o feature).
Un client si presenta al server con una lista di configurazioni che è predisposto ad utilizzare ed il server ne sceglie una: in questo scenario, per enumerare se una determinata configurazione è presente, è necessario forzare il client a presentarsi solo con quella configurazione.

La libreria OpenSSL, generalmente utilizzata per questi scopi, non dà completa libertà all’utilizzatore di impostare tutte le possibili configurazioni singolarmente (ad esempio, non è possibile forzare l’uso della compressione). Inoltre le scelte degli sviluppatori di OpenSSL (e dei suoi spinoff) sono state spesso indirizzate ad impedire ai programmatori di utilizzare configurazioni errate o obsolete, al punto che il supporto a SSL2 è ormai stato proprio rimosso e quello a SSL3 non viene più abilitato di default.

Dobbiamo quindi presentarci al server provando delle configurazioni obsolete ma le nuove librerie non ce lo permettono. Le vecchie librerie, dal canto loro, non supportano le nuove configurazioni.
A questo dobbiamo aggiungere che SSL/TLS non sono sempre stati implementati correttamente e le varie versioni dei diversi web server rispondono in modo diverso quando vengono messi di fronte a configurazioni che non supportano e, inoltre, che alcuni apparati di sicurezza filtrano i record SSL/TLS che presentano configurazioni deboli confondendo OpenSSL sul lato client.

E’ possibile aggirare tutte queste limitazioni, con una buona dose di intraprendenza, patchando opportunamente l’interprete Python 3.7 per operare con una versione volutamente obsoleta di OpenSSL.

Una volta in grado di testare, più o meno affidabilmente, la presenza o meno di determinate caratteristiche del protocollo HTTPS, quali verificare?

Abbiamo verificato l’eventuale presenza dei protocolli da SSL2 a TLS 1.3 poichè tutte le versioni precedenti a TLS 1.1 sono ormai deprecate. Nel caso nessun protocollo tra questi sia supportato, significa che il sito non supporta proprio il protocollo HTTPS.

Nel dettaglio, abbiamo verificato la presenza di:

• ciphersuite nel gruppo OpenSSL denominato aNULL, ovvero tutte quelle configurazioni che non autenticano il server (le chiavi di sessioni non sono firmate o cifrate con la chiave privata del server).
• ciphersuite nel gruppo OpenSSL denominato eNULL, ovvero le configurazioni senza crittografia.
• compressione: questa permette di ottenere informazioni testo in chiaro o risalire allo stesso.
• qualsiasi problema al certificato: questo è infatti elemento essenziale per l’effettiva protezione del canale.
• ciphersuite con cifrari deboli (I gruppi OpenSSL denominati LOW:RC2:RC4:DES,MD4:MD5,EXP:EXP1024,SEED:IDEA).
• ciphersuite con cifrari CBC (esistono attacchi contro questo modo d’uso dei cifrari).
• redirect HTTP verso URL con protocollo HTTP
• redirect da HTTP a HTTPS.

Inoltre, a puro scopo informativo, abbiamo anche cercato:

• la presenza di cifrari Perfect Forward Secrecy (PFS), ovvero che usano chiavi effimere (come ad esempio gli schemi di scambio basati su EECDH/ECDHE).
• il supporto all’estensione Server Name Indicator (SNI), fondamentale per gestire correttamente i certificati per i virtual host.
• l’effettiva presenza di un web server dietro la porta 443, ovvero che il canale stabilito permetta di comunicare tramite protocollo HTTP (e non, ad esempio, FTP come nel caso di SFTP).

Raccolti tutti questi dati è quindi necessario tirare le somme.
Abbiamo quindi deciso di dare un voto a ciascun sito, utilizando quattro possibili voti:

• Senza HTTPS. Il sito non supporta SSL/TLS.
• Grave. Il sito supporta SSL/TLS ma la sua configurazione lo rende aggirabile (ad esempio se ha un certificato non valido).
• Mal configurato. Il sito supporta SSL/TLS ma ha configurazioni non considerate idonee dalle buone pratiche moderne o addirittura deprecate. Attaccanti con le necessarie risorse o ben intenzionati potrebbero degradare la sicurezza del canale.
• Sicuro. La configurazione è ritenuta accettabile per gli standard attuali.

L’algoritmo che, date le caratteristiche riscontrate in un sito ne determina il voto, è spiegato in seguito.

In questa situazione un browser sceglierebbe TLS 1.3 anche qualora presenti ancora il supporto per SSL2.

Quindi è logico chiedersi se utilizzare il miglior voto, il peggiore o qualche altra combinazione.
Abbiamo scelto di assegnare il voto peggiore perchè l’idea alla base di questo strumento è quella di aiutare a far emergere ed evidenziare gli errori di configurazione.

Sempre in questa ottica, lo strumento non si limita a testare l’IP predefinito associato al dominio del sito ma testa tutti gli IP ritornati dalla relativa interrogazione del DNS. In più, nel caso il dominio effettui un redirect verso host esterni, anche questi ultimi vengono testati.

Il tutto allo scopo di individuare eventuali server obsoleti di cui si è perso contezza e che sono potenzialmente fuori controllo.

L’algoritmo di voto è dunque il seguente:

00. Inizialmente il voto è SICURO
01. Se non supporta SSL, assegna il voto SENZA_HTTPS e termina.
02. Se almeno uno tra SSL2 o SSL3 è supportato, merge con il voto GRAVE.
03. Se TLS1 è vero:
   3.1. Se nessuno tra TLS 1.1, TLS 1.2 e TLS 1.3 è supportato, merge con il voto GRAVE.
   3.2. Altrimenti merge con il voto MALCONFIGURATO.
04. Se tls 1.1 è supportato:
   4.1. Se nessuno tra TLS 1.2 e TLS 1.3 è supportato, merge con il voto GRAVE.
   4.2. Altrimenti merge con il voto MALCONFIGURATO.
05. Se il certificato non è valido, merge con il voto GRAVE.
06. Se è supportata la compressione, merge con il voto GRAVE.
07. Se sono supportati cifrari deboli, merge con il voto GRAVE.
08. Se sono supportati cifrari CBC, merge con il voto GRAVE.
09. Se almeno una tra aNULL o eNULL è supportata, merge con il voto GRAVE.
10. Se non fa redirect da HTTP a HTTPS, merge con il voto GRAVE.
11. Se c'è un redirect da HTTPS ad HTTP, merge con il voto GRAVE.

L’operazione di merge prende il voto corrente ed il nuovo voto ed imposta il voto corrente al peggiore tra i due.

Per la precisione, internamente i voti possibili sono cinque e non quattro ma, per semplicità di esposizione, si è scelto di raggruppare gli esiti nelle quattro categorie illustrate.
Il voto Grave comprende in realtà due voti interni che delineano i siti gravemente malconfigurati (es: quelli che supportano al massimo TLS 1.0) e quelli per cui HTTPS è completamente aggirabile (es: quelli che hanno il certificato non valido). Questo è il motivo per cui il voto Grave compare spesso nell’algoritmo precedente.

Va notato che alcuni siti non reagiscono bene quando varie richieste SSL/TLS vengono fatte in rapida successione, per cui è stato necessario implementare un meccanismo di backoff esponenziale per i tempi di invio delle richieste.

La spinosa questione degli aggiornamenti CMS

Tecnicamente parlando, verificare lo stato di aggiornamento dei CMS è un grossa sfida. I CMS non utilizzano una modalità standard di pubblicizzare il loro stato: rilevarli è già di per sè un’impresa, utilizzando in genere voluminose banche dati di artefatti da riconoscere ed una serie di controlli incrociati e di costanti aggiornamenti.

Lo strumento sviluppato internamente dal CERT-AGID utilizza la libreria WAD del CERN che permette di rendere questo problema più facilmente approcciabile.

Rimane tuttavia sempre un serio problema di base da affrontare: le tipologie di CMS sono tante e si aggiornano spesso. E’ quindi difficile che una libreria, a contributo prettamente volontario, possa stare sempre al passo con tutto questo.

Non sempre è possibile rilevare correttamente il CMS in uso. Temi e plugin “di protezione” cercano (giustamente) di rendere i CMS non riconoscibili per evitare proprio le scansioni automatiche e tentano in ogni modo di nascondere la versione al fine di evitare che gli strumenti di scansione la riconoscano .

Anche se il CMS viene riconosciuto, quasi tutti i plugin di sicurezza rimuovono di default la versione del CMS, rendendo quindi difficile o impossibile rilevare la versione esatta del CMS.

Va inoltre aggiunto che non esiste una lista ufficiale dei CMS e delle loro ultime versioni che sia costantemente aggiornata dai produttori, per cui è difficile individuare automaticamente quale sia l’ultima versione disponibile di un CMS.

Nonostante ciò è stato fatto uno sforzo per censire i CMS più noti, avendo cura di verificare l’ultima release disponibile nel momento della scansione e di integrare ulteriori funzioni per il rilevamento non presenti nella libreria WAD.

In fine, esiste un possibile fattore “temporale”: quando dei nuovi aggiornamenti sono rilasciati può passare un breve, auspicabilmente, intervallo di tempo prima che l’informazione sia recepita ed i CMS vengano aggiornati. Se viene fatta la scansione in questo lasso di tempo, i risultati risulteranno probabilmente peggiori di un scansione effettuata qualche giorno più avanti.

In sostanza, rilevare la presenza di un CMS è difficile, rilevarne la versione ancora di più, avere una lista di versioni CMS aggiornate è quasi impossibile e, se si ha sfortuna, i risultati risultano falsati negativamente.

Ma nonostante tutto questo, ci vogliamo provare!

Come è cambiata la situazione in questi 10 mesi di intervallo

Nel nostro primo monitoraggio, 20.018 domini erano stati correttamente testati sull’utilizzo del protocollo HTTPS, ovvero erano risolvibili, raggiungibili e non presentavano incongruenze tra i dati raccolti.

Nella nuova scansione il numero dei domini testati è sceso a 19.130. Si tratta di un decremento di 888 unità, pari a circa il 4,5%.

Sul fronte CMS, questa diminuizione è più accentuata, passando dai 20.018 siti correttamente testati (è una coincidenza che il numero corrisponda a quello delle rilevazioni HTTPS) ai 17.203 di quest’ultima scansione. Si tratta di una diminuzione significativa di 2815 unità assolute, pari al 14%.

Per il test dei CMS, un sito è considerato testato positivamente solo se la richiesta della pagina primaria ritorna un codice HTTP 200. Poichè sull’indice IPA non è riportato il protocollo utilizzato per raggiungere il dominio, le richieste sono state effettuate su entrambi i protocolli (HTTP e HTTPS). Questo esclude dal test i siti che fanno redirect verso nuovi domini ed è bene precisare che potrebbe aver falsato in parte i risultati ottenuti.

Non abbiamo indagato ulteriormente sui motivi di questa diminuzione. Senza troppe informazioni, è un azzardo anche solo fare ipotesi.

Panoramica sull’utilizzo del protocollo HTTPS

Passando a prendere in considerazione i siti correttamente testati, notiamo che la situazione HTTPS, nel lasso di tempo tra le due rilevazioni, è nettamente migliorata.

I siti votati come sicuri sono più che raddoppiati, passando da uno scarso 9% ad un più consistente 22% (da 1766 a 4149 unità).
Buone notizie anche sul fronte dei siti con gravi problemi di sicurezza, che presentano un calo del 14% (corrispondente a circa 2500 unità sul totale iniziale).

I siti senza HTTPS sono rimasti invariati in percentuale sul totale ma in termini assoluti sono passati da 445 a 340 unità, con un calo percentuale quindi di quasi il 25%.

La quantità di siti mal configurati è rimasta pressocchè invariata.

Dai dati aggregati (vedi in basso) emerge che l’azione correttiva maggiormente usata sia stata quella di implementare il redirect da HTTP ad HTTPS (seguita quantitativamente dalla correzione del certificato non valido).

Siti con gravi problemi di sicurezza

I siti con gravi problemi di sicurezza sono quelli per cui, come già accennato, è possibile aggirare la sicurezza del canale HTTPS.

Avevamo suddiviso questa categoria di siti in due sottocategorie: i siti con HTTPS facilmente aggirabili e quelli con HTTPS debole.

Come detto precedentemente, questo riflette il fatto che la categoria Grave è l’aggregazione di due voti internamente usati dallo strumento di testing.

La prima categoria comprende tutte le configurazioni che aprono falle strutturali nella sicurezza, nello specifico:

• Assenza di autenticazione (aNULL).
• Assenza di cifratura (eNULL).
• Supporto a SSL2 o SSL3.
• Massima versione TLS supportata pari a 1.1.
• Certificato non valido.
• Assenza di redirect da HTTP ad HTTPS.
• Redirect da HTTPS ad HTTP.

La seconda categoria comprende tutte le configurazioni con falle crittografiche (che richiedono quindi attacchi più sofisticati) e nello specifico:

• Supportano al massimo TLS 1.1.
• Supportano la compressione.
• Supportano cifrari deboli.
• Supportano cifrari in modo CBC.

In termini di numerosità percentuale di queste due categorie, la situazione è rimasta invariata: la maggior parte (circa il 95%) dei siti con voto Grave ricade nella categoria HTTPS facilmente aggirabile.

Se però analizziamo nel dettaglio i motivi che hanno portato i siti a finire nella categoria Grave possiamo evincere quale siano state le azioni correttive più adottate:

In questo grafico il delta è evidenziato in verde. Trattandosi, quest’ultime, di configurazioni scorrette, un delta negativo rappresenta un miglioramento.

Notiamo come l’azione correttiva più adottata sia stata quella di implementare un redirect da HTTP ad HTTPS, con quasi 4000 nuovi siti che implementano questa misura.

A stretto giro segue la correzione del certificato: quasi 3500 nuovi siti hanno corretto il loro certificato precedentemente non valido.

Infine, è interessante notare l’abbassamento delle percentuali di utilizzo di TLS 1.0 e 1.1: questo avanzamento è probabilmente dovuto al fatto che questi due protocolli sono ormai stati ampiamente deprecati.

In definitiva, si nota un miglioramento su tutti i fronti in questo scenario.

Siti mal configurati

I siti mal configurati sono quei siti che supportano configurazioni deprecate o non in linea con gli standard moderni.

Su questo fronte la situazione è rimasta invariata sia in termini percentuali che assoluti.

Questa categoria comprende i siti che supportano TLS 1.0, TLS 1.1 (e almeno un’altra versione superiore) e cifrari CBC ma non presentano le altre problematiche dei siti con voto Grave.

Siti sicuri

Dei siti alla fine considerati sicuri abbiamo raccolto in più alcune informazioni a fini statistici, come la presenza di ciphersuite PFS e di TLS 1.3.

In termini assoluti, i numeri sono più che raddoppiati come era facile aspettarsi dal fatto che i siti sicuri sono raddoppiati in percentuale sul totale.

In termini di percentuali relative alla categoria, tutti i siti sicuri supportano ciphersuite PFS (forse questo è un po’ un argomento circolare dato che i siti sicuri sono tutti quelli che non presentano ciphersuite problematiche, il che lascia solo, o quasi solo, quelle che supportano PFS).

Soltanto il 40% circa dei siti sicuri supporta TLS 1.3 (questo numero non è mostrato direttamente in figura). Notare che questa percentuale non è riferita al totale dei siti: se la riportiamo sul totale, il numero diviene di poco inferiore al 9%.

Trivia

Nella prima scansione era risultato un sito che supportava al massimo SSL3 (quindi non più visitabile da anni). In questa non è stato riscontarto nessun sito che supporta al massimo SSL: non abbiamo indagato se il sito incriminato sia stato sistemato o spento.

In entrambe le scansioni sono stati trovati circa 8000 siti che hanno record DNS CNAME diverso dal loro dominio: questo fa pensare a siti con una configurazione per CDN o anti-DOS oppure ad una gestione degli stessi da parte di aziende esterne.

L’utilizzo di indirizzamento IPv6 (in concomitanza a IPv4) è rimasto inviariato al 2% del totale, pari a circa (450 unità).

Panoramica sullo scenario dei CMS

La situazione lato CMS nell’intervallo di tempo tra le due rilevazioni è complessivamente peggiorata.

I siti con CMS in versione aggiornata sono passati dal 13,7% del totale all’8,3%. Un calo del 52%.

I siti con CMS sicuramente non aggiornato, che ricordiamo non sono il complemento dei siti con CMS aggiornato per via della possibilità di non rilevare il CMS stesso o la sua versione, sono passati dal 23,1% al 30,1% dei siti totali.

Anche qui si ha un andamento negativo della tendenza con un peggioramento relativo dell’11%.

Come per la prima scansione, solo la metà dei siti ha un CMS che è stato rilevato dallo strumento di scansione. Questo può essere dovuto a misure di contenimento dell’Amministrazione o al più semplice fatto che non sono usati CMS (o almeno CMS noti).

Nell’ambito dei CMS rilevati, la resa dello strumento è migliorata poichè sono diminuiti i casi in cui la versione CMS non veniva rilevata.

Tipi di CMS rilevati

Ancora una volta WordPress si rivela il CMS più usato: viene usato due volte tanto il suo concorrente più prossimo (Joomla) e cinque volte tanto il terzo classificato (Drupal).

I primi tre CMS si confermano quindi essere WordPress, Joomla e Drupal. Non sono presenti testa a testa e l’utilizzo di altri tipi di CMS è decisamente più rarefatto.

Rispetto al precedente report, sono spariti i seguenti CMS: XOOPS, Orchard CMS e PHP-Nuke.

In termini di percentuali WordPress detiene ancora più della metà della fetta del mercato di riferimento.

Joomla si ferma a circa un quarto e Drupal a meno di un ottavo.

Curiosamente, si nota che l’utilizzo dei CMS ricorda una progressione geometrica con fattore 2.

Conclusioni

La situazione lato HTTPS è nettamente migliorata, evidenziando come le problematiche di sicurezza legate a questo aspetto siano principalmente dovute ad una cura delle configurazioni poco attenta (certificati scaduti, redirect mancanti) e che lo sforzo necessario a migliorare questo aspetto della Pubblica Amministrazione non è poi così titanico.

Sul lato dei CMS la situazione non è migliorata: va altresì detto che la misurazione dello stato di aggiornamento dei CMS è un’operazione necessariamente soggetta ad ampia fluttuazione dei risultati.

La valutazione della sicurezza dei sistemi della Pubblica Amministrazione non può certo solo basarsi sulla misurazione del numero di enti che hanno il CMS aggiornato e la configurazione del protocollo HTTPS sicura: questo vale soprattutto per HTTPS, la cui assenza potrebbe anche non comportare rischi per l’Amministrazione stessa e, in misura minore e più articolata, anche per l’aggiornamento di un CMS, che non porta necessariamente con sè migliorie alla sicurezza del sito.

Tuttavia questi due aspetti sono significativi, ed indicativi, della diffusione della cultura della cibersicurezza nazionale, qui in particolare nella Pubblica Amministrazione.
L’utilizzo corretto di HTTPS è una funzionalità basica di sicurezza che, a quasi 27 anni dal quel febbraio 1995 in cui nacque SSL, dovrebbe ormai essere fornita da tutte le Pubbliche Amministrazioni. Stiamo comunque parlando di aspetti di sicurezza che oggi, nel 2021, sono ampiamente agevolati nella loro implementazione, dalla comunità degli sviluppatori e sistemisti tramite strumenti di supporto alla configurazione, da associazioni non-profit per l’ottenimento gratuito di certificati, da strumenti per l’aggiornamento automatico di quest’ultimi e guide messe a disposizione.

Con l’avvento di TLS 1.3 e del protocollo QUIC (alla base di HTTP3 e che usa TLS 1.3 senza il layer di record) il problema di avere delle configurazione HTTPS sicure andrà via via scomparendo: TLS 1.3 è infatti pensato per essere già sicuro di default.

Raccomandiamo alle amministrazioni che non hanno stringenti necessità di compatibilità con vecchi browser (dovrebbe essere sempre questo il caso per i portali istituzionali) di passare all’utilizzo del protocollo TLS 1.3 quanto prima e semplificarsi così l’onere della gestione della configurazione HTTPS.

Considerazioni simili possono essere fatte sull’aggiornamento dei CMS. Ormai tutti i principali CMS disponibili si sono sensibilizzati sugli aspetti di sicurezza visto che la regola principe per la sicurezza di un CMS è quella di mantenerlo aggiornato.

Per questo motivo, i CMS permettono il loro aggiornamento automatico o presentano sistemi automatizzati di notifica della presenza di una nuova versione. Anche quando viene fatto manualmente, l’aggiornamento non richiede tanto maggiore sforzo del cliccare su di un pulsante.

CMS e plugin non aggiornati sono uno dei principali vettori di attacco utilizzati dai malintenzionati. Questi software sono continuamente sotto la lente dei criminali che, con poco o nessun sforzo, possono rilevarli (esistono numerosi strumenti in grado di rilevare versioni obsolete e vulnerabilità nei cms ed i relativi plugin) e lanciare attacchi a tappeto verso un gran numero di siti.

Sebbene una rete ben segmentata e la presenza di opportune restrizioni sui sistemi possano limitare i danni alla restante parte dell’infrastruttura da questo tipo di attacchi, il rischio che eventuali dati sensibili possano venire esfiltrati, unito al danno d’immagine che ne deriverebbe per l’Amministrazione, rimane sempre molto alto.

E’ quindi indispensabile, durante lo sviluppo di progetti dei sistemi informativi, garantire che le scelte implementative fatte non compromettano la possibilità di aggiornare costantemente il CMS che viene utilizzato.

E’ possibile scaricare il documento PDF con i risultati dalla prima rilevazione HTTPS qui mentre i risultati della seconda sono disponibili qui.