Google ha rilevato che il tuo sito utilizza un pacchetto di crittografia TLS obsoleto: come risolvere

Da qualche tempo a questa parte Chrome, così come gli altri browser principali, mostrano l’indicazione Non sicuro nella barra degli strumenti allorquando un sito web contenente almeno un form per il login non utilizzasse il protocollo HTTPS insieme con un certificato digitale valido e non scaduto: Sito sicuro su Chrome e Firefox, che cosa significa.

Grazie all’utilizzo del protocollo HTTPS le informazioni che si scambiano con il server web remoto non possono essere intercettate, monitorate e modificate da parte di altri utenti non autorizzati. Ed è proprio per questo motivo che tutti i principali player del settore stanno invitando i webmaster a passare prima possibile a HTTPS.
Iniziative come Let’s Encrypt (vedere Ottenere un certificato digitale wildcard per HTTPS con Let’s Encrypt) consentono chiunque gestisca un sito web di dotarsi gratuitamente di un certificato digitale.

Il provider italiano Aruba già da tempo fornisce gratis un certificato digitale anche a tutti i clienti in hosting: Certificato SSL Aruba, da oggi disponibile in hosting.
I vantaggi sono evidenti perché la procedura di emissione del certificato, di rinnovo dello stesso e di installazione è totalmente automatica ed è gestita da Actalis, controllata di Aruba.

Tutti i webmaster, comunque, anche coloro che gestiscono un sito non contenente form di login è bene si attivino prima possibile per migrare a HTTPS.
Con una decisione certamente discutibile, a partire dal mese di luglio 2018, Google Chrome potrebbe cominciare a visualizzare l’etichetta Non sicuro per tutti i siti web HTTP e quindi non soltanto per quelli che contengono form per il login: Chrome indicherà come non sicuri tutti i siti HTTP a partire da luglio.

Cosa fare se Google segnalasse l’utilizzo di un pacchetto di crittografia TLS obsoleto

Su alcuni siti web HTTPS, premendo il tasto F12 in Google Chrome così da accedere agli strumenti per gli sviluppatori, il browser di Google mostra il messaggio Connection – obsolete connection settings con una descrizione dell’errore che spesso corrisponde alla seguente: “The connection to this site uses TLS 1.2 (a strong protocol), ECDHE_RSA with P-384 (a strong key exchange), and AES_256_CBC with HMAC-SHA1 (an obsolete cipher)“.
Nella barra degli indirizzi del browser viene comunque riportata l’indicazione Sicuro ma Chrome segnala l’utilizzo di un cifrario obsoleto.

Di solito si tratta di sistemi Windows Server (tant’è vero che abbiamo trovato la stessa identica segnalazione in molti siti gestiti da Microsoft) e il problema affonda le sue radici nel fatto che Google ritiene ormai superato l’utilizzo dei vecchi cifrari RSA.

Fino ad oggi le segnalazioni di Chrome sull’utilizzo di un cifrario obsoleto sono passate sostanzialmente inosservate ai più.
Da qualche giorno, però, forse con uno dei più recenti aggiornamenti della sua Search Console, Google ha iniziato a inviare il seguente messaggio a diversi webmaster:

Scrive Google: “Google ha rilevato che il tuo sito utilizza un pacchetto di crittografia TLS obsoleto. (…) Di conseguenza, è più facile che terze parti intercettino la connessioni tra i tuoi utenti e il tuo sito“.

Utilizzando un tono peraltro piuttosto minaccioso e “imperativo”, Google parla di “problema” e invita il webmaster o comunque il responsabile del sito web ad “aggiornare la configurazione TLS del server“.

Per risolvere il problema sui sistemi Windows Server è indispensabile possedere un certificato digitale firmato con una chiave ECDSA (Elliptic Curve Digital Signature Algorithm) e assicurarsi di disattivare i cifrari ritenuti ormai superati.

Come richiedere e installare un certificato HTTPS con chiave ECDSA su Windows Server

Se si disponesse di un server dedicato o di una macchina in cloud, per risolvere il problema legato alla segnalazione di Google nella Search Console (peraltro recentemente ammodernata e arricchita: Google Search Console, cos’è e quali sono le novità della nuova versione) si dovrà dapprima contattare una certification authority (CA), responsabile dell’emissione del nuovo certificato digitale, e verificare che essa possa firmare i certificati con una chiave ECDSA.

In Windows Server si dovrà quindi applicare la seguente procedura:

1) Premere la combinazione di tasti Windows+R e digitare mmc.
2) Scegliere File, Aggiungi/rimuovi snap-in, selezionare Certificati dal menu di sinistra quindi Aggiungi.
3) Selezionare Account del computer quindi Computer locale e, infine, premere OK.

4) Cliccare con il tasto destro su Personale quindi scegliere Tutte le attività, Operazioni avanzate, Crea richiesta personalizzata.
5) Premere tre volte il pulsante Avanti e alla comparsa della finestra in figura cliccare su Dettagli quindi su Proprietà.

6) Come Nome descrittivo si deve indicare il nome a dominio del proprio sito (esempio: nomedeldominio.it).
Nella scheda Soggetto, invece, si dovranno selezionare almeno le voci Nome comune (Common name, CN) e Paese (Country, C).
Come valore per la prima si dovrà inserire *.nomedeldominio.it (si otterrà un certificato wildcard valido anche per gli eventuali sottodomini); come Paese basterà digitare IT).

In entrambi i casi, si dovrà fare clic su Aggiungi per inserire i valori nella richiesta di emissione del certificato digitale (CSR).

7) Portandosi nella scheda Chiave privata, si dovrà fare clic su Provider del servizio di crittografia (CSP) (Cryptographic Service Provider), disattivare tutte le voci attive e spuntare solamente ECDSA_P256, Microsoft Software Key Storage Provider.

8) In corrispondenza di Opzioni chiave è consigliabile attivare la casella Consenti esportazione chiave privata in modo da poter trasferire il certificato, ad esempio, da un server all’altro.

9) Per concludere, si dovrà fare clic su Applica quindi su OK e, ancora, su Avanti.
Windows Server chiederà di indicare il nome del file all’interno del quale memorizzare la richiesta di emissione del certificato digitale con chiave ECDSA.

Il file può essere salvato con estensione .req oppure come .csr.

10) Inviare alla CA il file di richiesta (.req o .csr) e attendere la generazione del proprio certificato digitale con chiave ECDSA.

11) Una volta ottenuto il certificato in formato .cer, basterà cliccare di nuovo – con il tasto destro del mouse – sulla voce Personale (ripetere eventualmente i passaggi da 1 a 3) quindi scegliere Tutte le attività, Importa dal menu contestuale.

12) Dopo aver fatto clic su Avanti, basterà scegliere il file .cer trasmesso dalla CA e seguire la procedura passo-passo per l’importazione del certificato.

13) Eseguendo l’utilità gratuita IIS Crypto, già presentata nell’articolo Ottenere un certificato HTTPS gratuito (SSL/TLS) per IIS su Windows Server, si dovrà fare clic sul pulsante Best practices quindi disattivare la casella MD5 nel riquadro Hashes enabled.

IIS Crypto provvede a disattivare i protocolli, i cifrari, i meccanismi di hashing e i sistemi di scambio delle chiavi che non sono ritenuti più affidabili e che, anche nel recente passato, sono stati (e sono tutt’oggi) bersaglio di attacchi.

Suggeriamo di non disattivare alcun cifrario nella sezione Cipher Suites perché alcuni di essi sono indispensabili, ad esempio, per il corretto funzionamento del Desktop remoto (RDP). Disabilitandoli e riavviando il server si potrebbe non essere più in grado di accedervi (visualizzazione del messaggio Errore interno da parte di Desktop remoto).

Semmai, nella sezione Cipher Suites, può essere utile spostare in cima alla lista le voci seguenti:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

14) La gestione dei cifrari con IIS Crypto necessita il riavvio della macchina mentre non è richiesto per la generazione della CSR, l’importazione del certificato e l’impostazione dello stesso nella sezione Binding di IIS per il sito web d’interesse.

Applicando le indicazioni illustrate in quest’articolo neppure Chrome mostrerà più alcun messaggio d’allerta premendo il tasto F12.