TLS/SSL — La Comunicazione Sicura sul Web

TLS è il protocollo che rende possibile fidarsi di un sito web. Ogni volta che il browser mostra il lucchetto nella barra degli indirizzi, TLS sta lavorando in background per garantire che nessuno possa leggere o alterare i dati in transito.

1. Da SSL a TLS: Storia e Vulnerabilità

Le versioni di SSL (1994–1996)

Secure Sockets Layer (SSL) nacque in Netscape per proteggere le transazioni e-commerce dei primi anni ‘90.

• SSL 1.0: Non rilasciato pubblicamente — conteneva falle critiche scoperte internamente.
• SSL 2.0 (1995): Prima versione pubblica. Aveva debolezze strutturali gravi: possibilità di downgrade attack sugli algoritmi negoziati e nessuna protezione contro la troncatura della connessione.
• SSL 3.0 (1996): Riprogettazione completa. Rimase in uso per quasi vent’anni, ma nel 2014 l’attacco POODLE (Padding Oracle On Downgraded Legacy Encryption) ne dimostrò l’insicurezza fondamentale nel modo in cui gestiva il padding in modalità CBC. RFC 7568 ne ha vietato l’uso nel 2015.

L’era TLS (1999–oggi)

Nel 1999 l’IETF ha standardizzato il protocollo come Transport Layer Security (TLS), mantenendo la compatibilità strutturale con SSL 3.0 ma correggendone le debolezze.

TLS 1.3 rappresenta una discontinuità netta: ha eliminato decine di algoritmi deboli accumulati nei vent’anni precedenti e ha ridisegnato l’handshake per ridurre la latenza e migliorare la privacy per default.

2. Architettura di TLS

TLS si posiziona tra il livello applicativo e il livello di trasporto (TCP):

Il protocollo è organizzato in due strati sovrapposti.

TLS Record Protocol (strato inferiore)

È il motore del protocollo: si occupa di tutto quello che accade ai dati prima di scenderli su TCP.

Per ogni blocco di dati applicativi esegue in sequenza:

1. Frammentazione in record da massimo 16 KB.
2. Compressione (eliminata in TLS 1.3 — era sfruttata dall’attacco CRIME).
3. Cifratura + autenticazione del record con la chiave di sessione negoziata.
4. Aggiunta dell’intestazione del record (tipo, versione, lunghezza) e invio su TCP.

Protocolli di livello superiore

Sopra al Record Protocol operano quattro sotto-protocolli:

3. I Tre Pilastri: Confidenzialità, Integrità, Autenticazione

HTTPS non è altro che HTTP trasportato dentro un tunnel TLS. La differenza fondamentale rispetto a HTTP in chiaro:

• Confidenzialità: i dati sono cifrati con crittografia simmetrica (AES, ChaCha20). Anche se qualcuno intercetta il traffico, vede solo ciphertext.
• Integrità: ogni record include un codice di autenticazione. Se anche un solo byte viene alterato in transito, il destinatario se ne accorge e chiude la connessione.
• Autenticazione: il server dimostra la propria identità tramite un certificato digitale firmato da una CA fidata. Il client sa con certezza di star parlando con il server giusto e non con un impostore (man-in-the-middle).

4. Message Authentication Code (MAC) e AEAD

Il problema dell’integrità

La crittografia da sola non basta: un attaccante che non può leggere i dati potrebbe comunque modificarli in modo mirato (attacchi di tipo bit-flipping). Il MAC risolve questo.

Come funziona il MAC

$$\text{MAC} = \text{HMAC}(\text{chiave_segreta},\ \text{messaggio})$$

Il mittente calcola il MAC del messaggio e lo allega. Il destinatario ricalcola il MAC sul messaggio ricevuto e confronta: se non coincide, il messaggio è stato alterato o la chiave è sbagliata. In TLS il MAC usa HMAC (Hash-based MAC) con funzioni come SHA-256 o SHA-384.

AEAD in TLS 1.3

TLS 1.3 ha abbandonato il modello separato “cifra poi autentica” in favore di AEAD (Authenticated Encryption with Associated Data): un singolo algoritmo che cifra e autentica in un passo solo, eliminando un’intera classe di vulnerabilità legate all’ordine delle operazioni.

Le due cipher suite AEAD obbligatorie in TLS 1.3:

• AES-128-GCM — hardware-accelerato (AES-NI) su CPU moderne
• ChaCha20-Poly1305 — ottimale su dispositivi senza AES-NI (mobile, IoT)

5. Certificati Digitali X.509 e Catena di Fiducia

Struttura di un certificato X.509

Un certificato è un documento firmato digitalmente che lega una chiave pubblica a un’identità. I campi principali:

Tipi di certificato

• DV (Domain Validated): verifica solo che il richiedente controlli il dominio. Emesso in pochi minuti (es. Let’s Encrypt). Sufficiente per la maggior parte dei siti.
• OV (Organization Validated): verifica anche l’esistenza legale dell’organizzazione. Più costoso e lento.
• EV (Extended Validation): verifica approfondita dell’identità. Usato da banche e istituzioni.

La Catena di Certificazione

Nessun browser si fida direttamente del certificato di un sito web. La fiducia si propaga attraverso una catena:

Le Root CA (es. DigiSign, Sectigo, ISRG per Let’s Encrypt) sono pre-installate nel sistema operativo e nel browser — è il Trust Store. Il browser risale la catena dalla foglia fino a trovare una Root CA che riconosce. Se la catena è valida e nessun certificato è scaduto o revocato, la connessione è considerata sicura.

Revoca dei certificati

Se una chiave privata viene compromessa, il certificato deve essere revocato prima della scadenza. I due meccanismi:

• CRL (Certificate Revocation List): lista periodica di certificati revocati, pubblicata dalla CA. Efficace ma voluminosa.
• OCSP (Online Certificate Status Protocol): il browser interroga la CA in tempo reale per lo stato del singolo certificato. OCSP Stapling sposta questa verifica sul server, che allega la risposta OCSP già firmata al proprio certificato durante l’handshake, eliminando un round-trip aggiuntivo.

6. Cipher Suite

Una cipher suite è la combinazione di quattro algoritmi che client e server concordano di usare per una sessione:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 │     │     │        │           │
 │     │     │        │           └── Hash per HMAC/PRF
 │     │     │        └────────────── Cifratura simmetrica + modalità
 │     │     └─────────────────────── Algoritmo di autenticazione
 │     └───────────────────────────── Algoritmo di scambio chiavi
 └─────────────────────────────────── Protocollo

Forward Secrecy (FS)

La Forward Secrecy (o Perfect Forward Secrecy, PFS) garantisce che la compromissione della chiave privata del server in futuro non permetta di decifrare il traffico registrato oggi.

Senza FS (scambio chiavi RSA): il pre-master secret è cifrato con la chiave pubblica del server. Chi registra il traffico oggi e ruba la chiave privata domani può decifrare tutto retroattivamente.

Con FS (scambio chiavi ECDHE — Ephemeral Elliptic Curve Diffie-Hellman): le chiavi di sessione vengono generate ex-novo per ogni connessione usando parametri DH effimeri che vengono distrutti subito dopo. Non esiste materiale crittografico che permetta la decifratura postuma.

TLS 1.3 ha reso obbligatoria la Forward Secrecy eliminando RSA e DH statici dallo scambio chiavi.

Cipher Suite in TLS 1.3

In TLS 1.3 la cipher suite specifica solo la cifratura AEAD e la funzione hash (lo scambio chiavi è sempre ECDHE):

7. L’Handshake TLS

TLS 1.2 — Handshake in 2-RTT

Client                                          Server
  │                                               │
  │── ClientHello ────────────────────────────────▶│
  │   (versioni TLS, cipher suites, Client Random) │
  │                                               │
  │◀─ ServerHello ─────────────────────────────────│
  │   (versione scelta, cipher suite, Server Random)│
  │◀─ Certificate ─────────────────────────────────│
  │   (certificato X.509 del server)               │
  │◀─ ServerKeyExchange ───────────────────────────│
  │   (parametri ECDHE)                            │
  │◀─ ServerHelloDone ─────────────────────────────│
  │                                               │
  │── ClientKeyExchange ──────────────────────────▶│
  │   (chiave pubblica ECDHE effimera del client)  │
  │── ChangeCipherSpec ───────────────────────────▶│
  │── Finished (hash di tutti i messaggi) ────────▶│
  │                                               │
  │◀─ ChangeCipherSpec ─────────────────────────────│
  │◀─ Finished ─────────────────────────────────────│
  │                                               │
  │◀══════════ Dati Applicativi Cifrati ═══════════▶│

Questo schema richiede 2 round-trip (2-RTT) prima che i dati possano fluire. I due lati calcolano indipendentemente il pre-master secret tramite ECDH, da cui derivano le chiavi di sessione simmetriche usando una funzione pseudo-random (PRF).

TLS 1.3 — Handshake in 1-RTT

TLS 1.3 ha ottimizzato l’handshake eliminando messaggi ridondanti e anticipando lo scambio ECDH:

Client                                          Server
  │                                               │
  │── ClientHello ────────────────────────────────▶│
  │   (versioni, cipher suites, key_share ECDHE)   │
  │                                               │
  │◀─ ServerHello ─────────────────────────────────│
  │   (cipher suite, key_share ECDHE del server)   │
  │◀─ {Certificate} ───────────────────────────────│  ← già cifrato
  │◀─ {CertificateVerify} ─────────────────────────│
  │◀─ {Finished} ──────────────────────────────────│
  │                                               │
  │── {Finished} ─────────────────────────────────▶│
  │                                               │
  │◀══════════ Dati Applicativi Cifrati ═══════════▶│

Le differenze chiave rispetto a TLS 1.2:

• Il client invia i parametri ECDH già nel ClientHello: il server può derivare le chiavi di sessione e cifrare la propria risposta prima del secondo round-trip.
• Il certificato e il Finished viaggiano già cifrati — un attaccante passivo non vede nemmeno quale certificato usa il server.
• 0-RTT (Early Data): se client e server si sono già connessi in precedenza, TLS 1.3 permette di inviare dati applicativi già nel primo messaggio, azzerando la latenza dell’handshake. Ha però limitazioni: non è protetto contro i replay attack, quindi va usato solo per operazioni idempotenti (es. GET HTTP).

8. Strumenti Pratici

Ispezionare un certificato con OpenSSL

# Connettersi e vedere il certificato
openssl s_client -connect example.com:443 -showcerts

# Decodificare un certificato .pem
openssl x509 -in certificato.pem -text -noout

# Verificare cipher suite e versione TLS negoziate
openssl s_client -connect example.com:443 -tls1_3

Testare la configurazione TLS di un server

# Vedere la versione TLS e la cipher suite usata
curl -vI https://example.com 2>&1 | grep -E "TLS|cipher|issuer"

# Forzare TLS 1.2 per verificare compatibilità
curl --tlsv1.2 https://example.com

Cosa guardare nel browser

In qualsiasi browser moderno: apri i DevTools (F12) → tab Security (Chrome) o Privacy e Sicurezza → clicca su “Visualizza certificato” per vedere:

• Versione TLS negoziata
• Cipher suite usata
• Catena di certificazione completa
• Date di validità e fingerprint

Conclusioni

TLS è trasparente per l’utente finale, ma la sua correttezza dipende da decisioni di configurazione prese dall’amministratore del server. I punti critici da tenere a mente:

• Usare TLS 1.3 dove possibile; mantenere TLS 1.2 solo per compatibilità con client legacy.
• Abilitare solo cipher suite con Forward Secrecy (ECDHE).
• Tenere i certificati aggiornati — Let’s Encrypt offre certificati gratuiti con rinnovo automatico via ACME.
• Verificare periodicamente la configurazione con tool come SSL Labs (assegna un voto A/B/F alla configurazione TLS di un server pubblico).