Certificati SSL/TLS spiegati: cosa sono e perche sono importanti

Perche SSL/TLS continua a creare problemi

Si potrebbe pensare che ormai SSL/TLS sia un problema risolto. Ogni browser mostra un lucchetto. Let's Encrypt ha reso gratuiti i certificati. I provider di hosting offrono HTTPS con un clic. Eppure, continuiamo a trovare certificati configurati male su siti di produzione ogni settimana. Certificati scaduti, catene incomplete, avvisi di contenuto misto, header HSTS mancanti. Non sono casi limite: sono errori di routine che erodono la fiducia e penalizzano il posizionamento nei motori di ricerca.

Questa guida spiega come funziona realmente TLS, cosa significano in pratica i diversi tipi di certificato, come automatizzare la gestione dei certificati e quali configurazioni errate troviamo piu spesso durante gli audit di sicurezza per le aziende di Lugano e della Svizzera.

Breve storia: SSL, TLS e perche i nomi persistono

SSL (Secure Sockets Layer) fu sviluppato da Netscape a meta degli anni '90. SSL 2.0 usci nel 1995, SSL 3.0 nel 1996. Entrambi presentavano gravi falle crittografiche. TLS (Transport Layer Security) 1.0 sostitui SSL 3.0 nel 1999, e il protocollo si e evoluto attraverso TLS 1.1 (2006), TLS 1.2 (2008) e TLS 1.3 (2018).

Oggi, solo TLS 1.2 e TLS 1.3 sono considerati sicuri. Tutti i principali browser hanno abbandonato il supporto per TLS 1.0 e 1.1. Nonostante cio, la gente continua a dire "certificato SSL" perche il termine e rimasto nell'uso comune. Quando in questo articolo diciamo certificato SSL, intendiamo un certificato utilizzato con il protocollo TLS.

Come funziona l'handshake TLS

Ogni volta che il browser si connette a un sito HTTPS, avviene un handshake TLS prima che qualsiasi dato venga scambiato. Comprendere questo processo aiuta a diagnosticare i problemi quando qualcosa va storto.

Handshake TLS 1.2 (semplificato)

1. Client Hello - Il browser invia al server un elenco delle suite di cifratura supportate, la versione TLS e un numero casuale.
2. Server Hello - Il server sceglie una suite di cifratura dall'elenco del client, invia il proprio numero casuale e il suo certificato.
3. Verifica del certificato - Il browser verifica il certificato rispetto al proprio archivio di Certificate Authority (CA) fidate. Controlla la catena di fiducia, la data di scadenza e il nome del dominio.
4. Scambio delle chiavi - Utilizzando la suite di cifratura concordata, entrambe le parti generano un segreto condiviso (pre-master secret). Con lo scambio di chiavi RSA, il client lo crittografa con la chiave pubblica del server. Con Diffie-Hellman (DHE/ECDHE), entrambe le parti contribuiscono alla generazione del segreto condiviso.
5. Chiavi di sessione - Entrambe le parti derivano chiavi di sessione simmetriche dal segreto condiviso e dai numeri casuali.
6. Fine - Entrambe le parti inviano un messaggio "Finished" crittografato con le nuove chiavi di sessione, confermando il successo dell'handshake.

Questo processo richiede due round trip (2-RTT) in TLS 1.2.

Handshake TLS 1.3: piu veloce e semplice

TLS 1.3 riduce questo a un singolo round trip (1-RTT). Rimuove le suite di cifratura obsolete, impone la forward secrecy (solo scambio di chiavi ECDHE) e combina i passaggi. Il risultato: connessione piu rapida e sicurezza piu forte di default.

TLS 1.3 supporta anche la ripresa 0-RTT per i visitatori di ritorno, sebbene questa funzionalita presenti rischi di replay attack e debba essere configurata con attenzione.

Caratteristica	TLS 1.2	TLS 1.3
Round trip handshake	2-RTT	1-RTT (ripresa 0-RTT)
Forward secrecy	Opzionale (dipende dalla cifratura)	Obbligatoria
Scambio chiavi RSA	Supportato	Rimosso
Suite di cifratura	37+	5
Vulnerabilita note	BEAST, POODLE (mitigate)	Nessuna attualmente

Tipi di certificato: DV, OV e EV

Non tutti i certificati sono uguali. I tre tipi principali differiscono per livello di validazione, costo e cio che comunicano agli utenti.

Certificati Domain Validated (DV)

I certificati DV dimostrano che si controlla il dominio. La CA lo verifica attraverso uno di tre metodi: posizionando un file specifico sul server web, aggiungendo un record DNS TXT o rispondendo a un'email a un indirizzo amministrativo del dominio. Il processo e completamente automatizzato e richiede pochi minuti.

Costo: Gratuito (Let's Encrypt, ZeroSSL) fino a ~10 CHF/anno

Ideale per: Blog, siti personali, siti di piccole imprese, la maggior parte delle applicazioni web

Limitazione: Chiunque puo ottenerne uno, compresi i siti di phishing. Un certificato DV dice "la connessione e crittografata", non "il sito e legittimo".

Certificati Organization Validated (OV)

I certificati OV richiedono che la CA verifichi che l'organizzazione dietro il dominio esista realmente. Cio comporta la verifica dei documenti di registrazione aziendale, la verifica telefonica e talvolta la conferma dell'indirizzo fisico. Il processo richiede 1-3 giorni lavorativi.

Costo: 50-200 CHF/anno

Ideale per: Siti aziendali dove l'identita organizzativa e importante

Limitazione: I browser non distinguono visivamente i certificati OV da quelli DV. Gli utenti dovrebbero ispezionare i dettagli del certificato per vedere la differenza.

Certificati Extended Validation (EV)

I certificati EV richiedono la validazione piu rigorosa. La CA verifica l'esistenza legale, l'esistenza operativa, l'indirizzo fisico e che il richiedente abbia l'autorita per richiedere il certificato. Questo processo puo richiedere 1-2 settimane.

Costo: 100-500+ CHF/anno

Contesto storico: I certificati EV mostravano il nome dell'azienda in una barra degli indirizzi verde. Tutti i principali browser hanno rimosso questa distinzione visiva tra il 2019 e il 2020.

Valore attuale: Discutibile. Alcuni settori regolamentati li richiedono ancora, e alcuni sostengono che il rigoroso processo di verifica filtri i malintenzionati. Ma il beneficio pratico per l'utente e in gran parte scomparso.

Let's Encrypt e il protocollo ACME

Let's Encrypt e stato lanciato nel 2016 e ha cambiato radicalmente il panorama dei certificati. Fornisce certificati DV gratuiti utilizzando il protocollo ACME (Automatic Certificate Management Environment), che automatizza l'intero processo di emissione e rinnovo.

Come funziona ACME

Il protocollo ACME definisce un modo standard per un client (come Certbot) di dimostrare il controllo del dominio a una CA (come Let's Encrypt) e ricevere un certificato.

1. Il client genera una coppia di chiavi account e si registra presso la CA.
2. Il client richiede un certificato per un dominio, e la CA risponde con un insieme di sfide.
3. Il client completa una sfida (HTTP-01: posizionare un file in /.well-known/acme-challenge/, oppure DNS-01: creare un record DNS TXT).
4. La CA verifica la sfida ed emette il certificato.
5. Il client installa il certificato e programma il rinnovo (i certificati Let's Encrypt sono validi 90 giorni).

Strumenti di automazione

• Certbot - Il client ACME originale. Funziona con Apache e Nginx. Esegui certbot --nginx e gestisce tutto.
• acme.sh - Un client ACME basato su shell script. Leggero, senza dipendenze oltre shell e curl.
• Caddy - Un web server con HTTPS automatico integrato.
• Traefik - Un reverse proxy che gestisce automaticamente i certificati Let's Encrypt per applicazioni containerizzate.

La finestra di validita di 90 giorni

I certificati Let's Encrypt scadono dopo 90 giorni, e questo e intenzionale. Periodi di validita piu brevi riducono la finestra di danno se una chiave privata viene compromessa e incoraggiano l'automazione. Se si configura correttamente il rinnovo automatico, non ci si pensa piu. Se non lo si fa, ci si sveglia con un certificato scaduto e un sito che i browser bloccano.

Abbiamo visto aziende a Lugano perdere intere giornate di traffico web perche un cron job di rinnovo Let's Encrypt falliva silenziosamente. L'automazione funziona solo se la si monitora.

Configurazioni errate comuni che troviamo negli audit

Quando eseguiamo valutazioni di sicurezza dei siti web per i clienti, i problemi con i certificati sono tra i risultati piu frequenti. Ecco quelli che incontriamo ripetutamente.

1. Contenuto misto (Mixed Content)

Questo accade quando una pagina viene servita tramite HTTPS ma carica alcune risorse (immagini, script, fogli di stile, font) tramite HTTP. I browser bloccano il contenuto misto attivo (script, iframe) e possono avvisare riguardo al contenuto misto passivo (immagini).

Come trovarlo: Apri la console sviluppatore del browser e cerca avvisi di contenuto misto. Oppure usa uno strumento come mixed-content-scan per scansionare l'intero sito.

Come risolverlo: Aggiorna tutti gli URL delle risorse per usare HTTPS. Imposta un header Content-Security-Policy con upgrade-insecure-requests come rete di sicurezza.

2. Certificati scaduti

Un certificato con periodo di validita scaduto fa si che i browser mostrino un avviso a pagina intera. La maggior parte degli utenti non procedera. Il sito e effettivamente offline.

Prevenzione: Automatizza il rinnovo e monitora le date di scadenza dei certificati. Imposta avvisi a 30, 14 e 7 giorni prima della scadenza.

3. Catena di certificati incompleta

Il certificato e firmato da una CA intermedia, che e firmata da una CA radice. I browser hanno le CA radice nel loro archivio di fiducia ma non sempre le intermedie. Il server deve inviare la catena completa: il certificato piu tutti i certificati intermedi.

Se l'intermedio manca, alcuni browser (specialmente su mobile o sistemi piu vecchi) non riusciranno a validare il certificato anche se e perfettamente valido.

4. Dominio errato / Mancata corrispondenza SAN

Il Common Name o i Subject Alternative Names (SAN) del certificato devono corrispondere al dominio che l'utente sta visitando. Un certificato per example.com non funzionera per www.example.com a meno che www.example.com non sia elencato come SAN.

5. Utilizzo di TLS 1.0 o 1.1

Alcuni server hanno ancora TLS 1.0 o 1.1 abilitati per "compatibilita". Questa compatibilita non serve quasi piu nessuno e espone a vulnerabilita note. Disabilitali.

6. Suite di cifratura deboli

Supportare cifrature come RC4, 3DES o cifrature di livello export e un rischio per la sicurezza. Le configurazioni moderne dovrebbero supportare solo cifrature AEAD (AES-GCM, ChaCha20-Poly1305) con forward secrecy.

HSTS: HTTP Strict Transport Security

Anche con HTTPS configurato perfettamente, un utente che digita example.com nel browser fara inizialmente una richiesta HTTP. Il server reindirizza a HTTPS, ma quella prima richiesta e non crittografata e vulnerabile a un attacco man-in-the-middle (SSL stripping).

HSTS risolve questo problema. Quando invii l'header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Il browser ricorda che il sito deve essere acceduto solo tramite HTTPS. Per la durata di max-age, il browser convertira automaticamente qualsiasi richiesta HTTP in HTTPS prima di inviarla.

Per un approfondimento su HSTS e altri header di sicurezza, consulta la nostra guida completa agli header di sicurezza.

SSL/TLS e SEO

Google ha confermato HTTPS come segnale di ranking nel 2014. Anche se inizialmente descritto come segnale "leggero", e diventato un'aspettativa di base. I siti senza HTTPS vengono contrassegnati con avvisi "Non sicuro" in Chrome, il che influenza direttamente il comportamento degli utenti.

Ecco cosa abbiamo osservato lavorando con i clienti sulla sicurezza informatica a Lugano e in tutta la Svizzera:

• I segnali di fiducia contano. Un avviso "Non sicuro" nella barra degli indirizzi aumenta il tasso di rimbalzo.
• HTTPS e necessario per HTTP/2 e HTTP/3. Questi protocolli offrono miglioramenti significativi delle prestazioni.
• Alcune API del browser richiedono un contesto sicuro. Geolocalizzazione, service worker, notifiche push e Clipboard API richiedono tutti HTTPS.
• I dati referrer vanno persi. Quando il traffico passa da un sito HTTPS a uno HTTP, l'header referrer viene rimosso.

Certificate Transparency

Certificate Transparency (CT) e un sistema di logging pubblico dove le CA devono registrare ogni certificato che emettono. Questo rende possibile rilevare certificati emessi erroneamente o ottenuti in modo fraudolento.

Come monitorare

• crt.sh - Un motore di ricerca gratuito per i log CT. Inserisci il tuo dominio per vedere ogni certificato mai emesso per esso.
• Facebook Certificate Transparency Monitoring - Invia notifiche quando viene emesso un nuovo certificato per il tuo dominio.
• Certspotter - Uno strumento di monitoraggio che avvisa sui nuovi certificati nei log CT.

Raccomandazioni pratiche

Basandoci su centinaia di valutazioni di sicurezza, ecco cosa raccomandiamo per qualsiasi azienda con un sito web:

1. Usa TLS 1.2 come minimo. Disabilita TLS 1.0 e 1.1. Se possibile, preferisci TLS 1.3.
2. Automatizza la gestione dei certificati. Usa Let's Encrypt con Certbot, o usa un provider che gestisca i certificati automaticamente (Cloudflare, Vercel, Netlify).
3. Monitora la scadenza dei certificati. Anche con l'automazione, le cose possono fallire. Imposta il monitoraggio.
4. Abilita HSTS. Inizia con un max-age breve (es. 300 secondi), testa accuratamente, poi aumenta a un anno.
5. Controlla la catena dei certificati. Usa SSL Labs per verificare che la catena completa sia servita correttamente.
6. Elimina il contenuto misto. Controlla ogni pagina, non solo la homepage.
7. Monitora i log CT. Sappi quando vengono emessi certificati per i tuoi domini.
8. Usa suite di cifratura forti. Segui la configurazione Modern o Intermediate di Mozilla.

Conclusione

I certificati SSL/TLS sono uno strato fondamentale della sicurezza web. Configurarli correttamente non e difficile, ma richiede attenzione ai dettagli che sono facili da trascurare: catene di certificati, automazione del rinnovo, contenuto misto, header HSTS e configurazione delle suite di cifratura.

Se non sei sicuro della tua configurazione attuale, esegui il tuo dominio attraverso SSL Labs e vedi cosa viene fuori. Se il voto e inferiore a una A, c'e lavoro da fare.

Hai bisogno di aiuto per proteggere il tuo sito web o desideri una valutazione di sicurezza professionale? Contatta il nostro team a Lugano. Aiutiamo le aziende in tutta la Svizzera con la sicurezza dei siti web, dalla configurazione dei certificati agli audit di sicurezza completi.