TLS e HTTPS Guida Avanzata: Handshake, Certificati, Versioni Sicure • Meteora Web Agency

Il tuo sito carica in HTTPS. Il lucchetto è verde. Eppure un giorno arriva la segnalazione: "certificato scaduto", "handshake fallito", "TLS version deprecated". Il cliente non capisce, il traffico cala, Google penalizza. Noi, di Meteora Web, lo vediamo ogni giorno nei progetti che ci arrivano in consulenza. TLS non è una spunta da mettere in una checklist: è un protocollo vivo, con versioni che muoiono, configurazioni che invecchiano e handshake che devono bilanciare sicurezza e latenza.

Questa guida è per chi già sa cos'è un certificato ma vuole capire come funziona davvero l'handshake, quali versioni usare e come evitare i buchi neri della configurazione. Partiamo da zero, ma senza paternali.

L'Handshake TLS: Cosa Succede in Quei Millisecondi

Ogni volta che un browser si connette al tuo server HTTPS, avviene un negoziato in 4-7 passaggi. Se un passaggio fallisce, niente connessione. Se è lento, l'utente percepisce ritardo. Noi abbiamo ottimizzato handshake per clienti e-commerce riducendo il time-to-first-byte del 30% solo sistemando la configurazione TLS.

Passo 1: Client Hello

Il browser manda un messaggio con le versioni TLS che supporta (es. 1.2, 1.3), i cifrari preferiti (suite crittografiche) e un numero random. Il server riceve e sceglie la combinazione più sicura tra quelle proposte.

Passo 2: Server Hello e Scambio Certificato

Il server risponde con la versione scelta, il cifrario selezionato, un suo random e il certificato X.509. Qui un errore comune: il certificato deve includere tutta la catena di fiducia (root CA + intermediate), altrimenti il browser rifiuta. Abbiamo visto server con catena incompleta e client che impazzivano su Android.

Passo 3: Scambio Chiavi e Verifica

Con TLS 1.2, c'è un ulteriore scambio per stabilire la chiave simmetrica (solitamente Diffie-Hellman effimero). Con TLS 1.3, tutto avviene in un unico round-trip riducendo la latenza. Dopo, client e server confermano che l'handshake è completo e iniziano a scambiare dati crittografati.

Errore comune: non usare ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Server configurati solo con RSA espongono a attacchi passivi. Noi, di Meteora Web, forziamo sempre ECDHE con curve P-256 o X25519 nei nostri deploy.

Versioni Sicure: TLS 1.2, 1.3 e le Vecchie Glorie

Oggi le uniche versioni da accettare sono TLS 1.2 e 1.3. TLS 1.0 e 1.1 sono deprecati da tutti i browser moderni e da PCI DSS. SSLv3 e inferiori sono da bloccare brutalmente. Ma attenzione: non basta disabilitarle, bisogna anche garantire che il server non le offra durante il negoziato. Abbiamo visto configurazioni Apache che dichiarano di supportare solo 1.2 ma in realtà accettano handshake downgrade se il client insiste.

Perché TLS 1.3 è Meglio

Meno round-trip: handshake completo in 1 RTT (contro 2 di 1.2). Con session resumption, addirittura 0-RTT (ma attenzione ai rischi di replay).
Cifrari più forti: abbandona RSA e CBC, ammette solo AEAD (AES-GCM, ChaCha20-Poly1305).
Perfect Forward Secrecy obbligatoria: se la chiave privata viene compromessa, le sessioni passate sono al sicuro.

Noi consigliamo di abilitare TLS 1.3 subito, e tenere 1.2 come fallback per client vecchi (es. browser di Windows 7 senza aggiornamenti). Ma mai scendere sotto 1.2.

Certificati: Non Solo Scadenza

I certificati hanno una gerarchia: Root CA (fidata nativamente) -> Intermediate CA -> tuo dominio. Se il server non invia l'intermediate, molti client (soprattutto mobile) falliscono la validazione. Noi risolviamo verificando sempre con openssl s_client -connect dominio:443 -showcerts.

Tipi di Certificato

DV (Domain Validated): basta provare il controllo del dominio. Ok per siti normali.
OV (Organization Validated): verifica anche l'azienda. Dà più fiducia visiva (ma pochi la notano).
EV (Extended Validation): mostra il nome verde nella barra. Oggi quasi scomparso, perché i browser lo mostrano come una nota, non più verde. Noi non lo consigliamo più – il costo extra non giustifica il beneficio.

Automazione con Let's Encrypt

Usiamo certbot su quasi tutti i server: rinnovo automatico ogni 90 giorni. Attenzione: abbiamo visto server dove il cron job si rompeva e il certificato scadeva senza preavviso. La ricetta: testare il rinnovo con certbot renew --dry-run settimanalmente e monitorare la scadenza con UptimeRobot o Prometheus.

Codice esempio per Nginx (server block minimo sicuro):

server {
    listen 443 ssl http2;
    server_name esempio.com;

    ssl_certificate /etc/letsencrypt/live/esempio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/esempio.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000" always;
}

Nota: ssl_prefer_server_ciphers off perché TLS 1.3 gestisce da solo la selezione. In TLS 1.2, invece, è meglio tenerlo on.

Verifica della Configurazione: Strumenti e Comandi

Prima di mettere in produzione, eseguiamo sempre questi controlli:

SSL Labs (Qualys): test completo online. Puntiamo a A+.
testssl.sh: script da terminale, ottimo per CI/CD. Esempio: ./testssl.sh --quiet https://tuodominio.com
OpenSSL s_client: per debug manuale. openssl s_client -connect dominio:443 -tls1_3 mostra dettagli handshake.

Errori Comuni e Come Risolverli

Mismatch tra Nome e SAN

Il certificato deve includere il nome esatto del dominio nel campo Subject Alternative Name (SAN). Se hai esempio.com e www.esempio.com, devi avere entrambi. Noi usiamo certificati wildcard (*.esempio.com) solo se servono molti subdomini, ma attenzione: non coprono esempio.com nudo.

Catena Incompleta

Il file fullchain.pem di Let's Encrypt contiene già l'intera catena. Se usi CA commerciali, unisci certificato + intermediate in un file. Verifica con: openssl verify -CAfile trusted-root.pem -untrusted intermediate.pem cert.pem.

HSTS Assente

L'header Strict-Transport-Security forza il browser a usare solo HTTPS per il dominio. Senza, un attacco MITM può declassare a HTTP. Imposta un max-age di almeno 6 mesi (63072000 secondi) e, dopo aver verificato che tutto funzioni in HTTPS, aggiungi includeSubDomains e preload (ma solo se sei sicuro).

In sintesi — Cosa Fare Adesso

Se gestisci server o sviluppi API, prendi queste azioni immediate:

Verifica le versioni TLS supportate dal tuo server. Usa testssl.sh o SSL Labs. Blocca subito TLS 1.0 e 1.1.
Controlla la catena del certificato con openssl s_client -showcerts. Se manca un intermediate, ricostruisci il file concatenato.
Abilita TLS 1.3 e configura solo cifrari sicuri (usa la lista sopra).
Attiva HSTS con max-age adeguato. Prima verifica che non ci siano risorse miste (HTTP e HTTPS) sul tuo sito.
Automatizza il rinnovo dei certificati e monitora la scadenza. Metti un alert quando mancano 30 giorni.
Testa la configurazione dopo ogni modifica. Un errore di sintassi può far cadere il server.

Questa guida è un approfondimento del nostro pilastro Crittografia e Sicurezza Dati. Se vuoi andare più a fondo su concetti come forward secrecy o attacchi a TLS, parti da lì.

Noi, di Meteora Web, lavoriamo ogni giorno con questi protocolli. Se hai dubbi sulla tua configurazione, non aspettare che sia il cliente a segnalarti un errore. Controlla oggi stesso.