Aggiornare le cipher suite su Windows Server (IIS) per maggiore sicurezza

Collegamenti rapidi

• Perché le cipher suite sono importanti

• Come verificare lo stato del tuo server

• Aggiornare le cipher suite

Gestisci un sito serio che gli utenti devono poter ritenere affidabile. Giusto? Vale la pena ricontrollarlo. Se il tuo sito è ospitato su Microsoft Internet Information Services (IIS), potresti ricevere qualche sorpresa: quando un client si connette al server tramite una connessione sicura (SSL/TLS), il server suggerisce una lista di opzioni di crittografia — e alcune di queste opzioni potrebbero non essere sicure.

Fornire una lista di cipher suite più sicure è gratuito e relativamente semplice. Questa guida passo dopo passo spiega come proteggere i tuoi utenti e il tuo server e come testare i servizi che usi per valutare il livello reale di sicurezza.

Perché le cipher suite sono importanti

IIS è facile da installare e gestire: ha un’interfaccia grafica familiare e gira su Windows. Tuttavia, i valori predefiniti di sicurezza non sono i migliori. Quando un browser stabilisce una connessione HTTPS (identificabile dall’URL che inizia con “https://“), il server risponde inviando una lista di cipher suite ordinate per preferenza. Il browser scorre la lista fino a trovare una suite che supporta e si instaura la connessione.

Il problema è che non tutte le suite sono equivalenti: alcune usano algoritmi moderni e robusti (ad esempio ECDHE con AES-GCM), altre sono più deboli (RSA senza PFS), e altre ancora sono datate o insicure (DES, RC4 in passato). Se il server propone anche suite deboli, un client potrebbe finire per usarne una e la sicurezza della sessione ne risente.

Importante: le impostazioni di default di IIS possono includere opzioni non ottimali. Aggiornare la lista e la priorità delle cipher suite riduce il rischio di connessioni insicure.

Come vedere dove sei arrivato

Prima di modificare la configurazione, valuta il punto di partenza. SSL Labs di Qualys fornisce un ottimo tester pubblico: https://www.ssllabs.com/ssltest/. Inserendo il nome del tuo dominio otterrai un’analisi dettagliata delle capacità TLS del server, delle cipher suite offerte e della valutazione (A/B/C ecc.).

Nota: il punteggio di SSL Labs è una guida. Alcune regole (ad esempio il forte bias contro RC4) servono a oscurare problemi di compatibilità noti ma non sempre indicano che un sito è malgestito. Usa il risultato come punto di partenza per migliorare la compatibilità e la sicurezza.

Passaggi per aggiornare le cipher suite su Windows Server

Di seguito una procedura passo-passo per modificare l’ordine delle cipher suite tramite l’Editor Criteri di Gruppo (Group Policy Editor). In alternativa, più avanti mostro strumenti che possono rendere la procedura visuale.

1. Premi Windows Key + R per aprire la finestra “Esegui”.
2. Digita gpedit.msc e premi Invio per avviare l’Editor Criteri di Gruppo.

3. Nel pannello sinistro espandi Computer Configuration → Administrative Templates → Network, quindi seleziona SSL Configuration Settings.
4. Nel pannello destro fai doppio clic su SSL Cipher Suite Order.

5. Per impostazione predefinita lo stato è “Not Configured”. Seleziona “Enabled” per abilitare la modifica del campo.

6. Il campo SSL Cipher Suites contiene una lunga stringa separata da virgole. Copia il contenuto in un editor di testo (Blocco note) e formattalo mettendo ogni suite su una riga per facilitare la lettura.
7. Crea la tua lista curata: rimuovi suite obsolete o insicure e ordina le rimanenti ragionevolmente (vedi sezione “Linee guida di ordinamento” più avanti).

Limite tecnico: il campo accetta al massimo 1.023 caratteri in totale; questo obbliga a scegliere e a condensare le voci perché i nomi delle suite sono lunghi.

8. Una volta pronta la stringa, riconverti l’elenco in una singola riga separata da virgole e incollalo nuovamente nel campo SSL Cipher Suites.
9. Clicca OK e riavvia il server per applicare le modifiche.

Dopo il riavvio, riesegui il test su SSL Labs. Se tutto è andato a buon fine, dovresti vedere un miglioramento nella valutazione.

Approccio alternativo: IIS Crypto

Se preferisci un’interfaccia grafica e preset testati, usa IIS Crypto di Nartac: https://www.nartac.com/Products/IISCrypto/Default.aspx. L’applicazione consente di abilitare/disabilitare protocolli, curve, ciphers e cipher suites con pulsanti e preset (ad esempio Best Practices, Modern). Dopo l’uso ricordati comunque di riavviare il server.

Linee guida per scegliere e ordinare le cipher suite

Usa queste euristiche per costruire la tua lista:

• Priorità al Forward Secrecy: preferisci ECDHE (o DHE) per assicurare Perfect Forward Secrecy.
• Preferisci AEAD: scegli suite con AES-GCM o CHACHA20-POLY1305 se disponibili.
• Evita suite con MD5 o con MAC basati su SHA1; preferisci SHA256/SHA384.
• Evita DES, 3DES, RC4 e suite note vulnerabili.
• Se la compatibilità con client legacy è indispensabile, tieni una lista separata e usa un approccio a più livelli (es. API o vhost dedicati per client moderni vs legacy).

Esempio (heuristico, non esaustivo): metti prima ECDHE con AES-GCM (256/128), poi ECDHE con AES-CBC con SHA384/SHA256, poi RSA se proprio necessario. Evita RC4 e 3DES.

Nota: non esiste una “singola lista perfetta”; la scelta dipende dai client che devi supportare (browser, dispositivi IoT, API di terze parti).

Controlli di accettazione e casi di test

Prima di considerare il lavoro concluso, verifica con questi test:

• Test funzionale: SSL Labs mostra A o A+ (se il tuo requisiti lo richiedono) per il dominio principale.
• Test di compatibilità: verifica che i browser e dispositivi target riescano a connettersi (Chrome, Edge, Safari, Firefox, iOS, Android, versioni aziendali se necessario).
• Test dell’applicazione: assicurati che integrazioni esterne (API, webhook, servizi di terzi) mantengano la connettività.
• Test di rollback: verifica di poter tornare rapidamente alla configurazione precedente se comparissero errori imprevisti.

Criteri di successo: server risponde con solo cipher suite approvate e le applicazioni critiche/utenti principali mantengono la connettività.

Checklist operativa (ruoli)

Amministratore di sistema / DevOps:

• Backup della chiave di registro o export della GPO corrente.
• Copia della stringa originale delle cipher suite in un file sicuro.
• Applicazione delle modifiche in ambiente di staging prima della produzione.
• Riavvio programmato del server.
• Esecuzione dei test SSL Labs e test di compatibilità.

Responsabile della sicurezza / CISO:

• Valutazione della policy aziendale su TLS e PFS.
• Coordinamento con il team applicativo per testare i client critici.

Sviluppatori / QA:

• Test di integrazione automatizzati per endpoint critici.
• Verifica di eventuali errori TLS nei log applicativi dopo la modifica.

Rischi, mitigazioni e compatibilità

Rischio: perdita di connettività per client legacy. Mitigazione: creare un piano di rollback, testare su staging e mantenere un canale per comunicare ai clienti eventuali requisiti minimi di aggiornamento.

Rischio: superamento del limite di 1.023 caratteri. Mitigazione: ridurre il numero di suite mantenendo solo le più efficaci; utilizzare strumenti che abbreviino l’elenco rimuovendo ridondanze.

Compatibilità: dispositivi più vecchi (vecchi browser, OS datati, alcuni dispositivi embedded) potrebbero non supportare ECDHE o AES-GCM. Valuta l’uso di host separati o configurazioni diverse per questi casi.

Mini-metodologia operativa (SOP rapido)

1. Raccogli configurazione corrente (esporta la stringa delle cipher suite).
2. Valuta con SSL Labs e identifica le suite deboli.
3. Prepara la nuova lista basata su ECDHE + AES-GCM e ordina per sicurezza/compatibilità.
4. Applica la modifica in GPO o tramite IIS Crypto.
5. Riavvia il server in manutenzione programmata.
6. Esegui test funzionali + SSL Labs.
7. Documenta e archivia la nuova configurazione.

Suggerimenti pratici e hardening aggiuntivo

• Disabilita protocolli obsoleti: TLS 1.0 e TLS 1.1 dovrebbero essere disabilitati se non indispensabili.
• Aggiorna regolarmente Windows Server e IIS alle patch di sicurezza.
• Considera HSTS per forzare connessioni HTTPS e ridurre downgrade attack.
• Monitora i log TLS per handshake falliti che possono indicare problemi di compatibilità.

Quando questa procedura fallisce o non è sufficiente

• Se hai dispositivi legacy che obbligano a mantenere suite insicure, valuta segmentazione del servizio o proxy TLS che offrano compatibilità verso l’esterno ma proteggano i backend.
• Se il tuo server è dietro a dispositivi di rete (load balancer, appliance TLS), devi applicare le stesse regole anche su quei dispositivi — altrimenti la configurazione locale di IIS viene bypassata.

Risorse utili

• SSL Labs: https://www.ssllabs.com/ssltest/
• Lista SChannel aggiornata (consigliata per riferimento): https://www.grc.com/miscfiles/SChannel_Cipher_Suites.txt
• IIS Crypto: https://www.nartac.com/Products/IISCrypto/Default.aspx

Riepilogo

Aggiornare le cipher suite di un server Windows che esegue IIS è una leva a basso costo e alto impatto per migliorare la sicurezza delle connessioni HTTPS. Testa sempre prima su staging, documenta l’attuale configurazione, applica le modifiche e verifica i risultati con strumenti esterni come SSL Labs. Mantieni un piano di rollback e comunica con gli stakeholder rilevanti.

Importante: la miglior configurazione dipende dai tuoi requisiti di compatibilità. Privilegia Forward Secrecy e algoritmi AEAD quando possibile.