TLS on My personal blog

mTLS: autenticare i servizi, non solo i server

Sat, 03 Oct 2026 09:00:00 +0200

Perché conta

Nel capitolo su TLS il server dimostra la propria identità al client con un certificato. Ma il client resta anonimo: TLS verifica che stiate parlando con banca.it, non che banca.it stia parlando con voi. Per un sito web va bene — l’utente si autenticherà dopo, con la password. Per due servizi che si parlano in un’architettura a microservizi, invece, non c’è nessun “dopo”: il servizio A deve sapere, subito e con certezza, che chi lo contatta è davvero il servizio B. Questo è il mutual TLS.

TLS normale contro mTLS

  flowchart TD
    subgraph TLS["TLS normale"]
        C1[Client] -->|verifica il cert del server| S1[Server]
        S1 -.client anonimo.-> C1
    end
    subgraph MTLS["mutual TLS"]
        C2[Servizio A] -->|presenta il proprio cert| S2[Servizio B]
        S2 -->|presenta il proprio cert| C2
        C2 <-.entrambi verificati.-> S2
    end

In mTLS il server, durante l’handshake, invia un messaggio CertificateRequest: chiede al client di presentare a sua volta un certificato. L’handshake si completa solo se entrambi i certificati sono validi e firmati da una CA di cui l’altro si fida. L’identità è reciproca e provata a livello di trasporto, prima che passi un solo byte applicativo.

Dove serve davvero

mTLS brilla dove non c’è un utente umano a digitare una password:

Microservizi: decine di servizi che si chiamano a vicenda dentro un cluster. mTLS dà a ciascuno un’identità crittografica e cifra tutto il traffico interno.
Zero Trust: il principio “mai fidarsi della rete” (vedi Zero Trust Architecture) richiede che ogni chiamata sia autenticata, anche dentro il perimetro. mTLS è il meccanismo.
API tra organizzazioni: due aziende che si scambiano dati possono legare l’accesso a un certificato invece che a una API key, che è solo una stringa da rubare.

L’identità sta nel certificato

La differenza rispetto a una API key è sostanziale. Una key è un segreto condiviso: chi la ruba diventa te. Un certificato client lega l’identità a una chiave privata che non lascia mai il servizio; sul filo viaggia solo una firma, mai il segreto. E un certificato ha una scadenza e si può revocare, mentre una key resta valida finché qualcuno non se ne accorge.

L’identità del chiamante viene letta dal campo del certificato, ad esempio il Subject o un SAN:

# generare un certificato client firmato dalla CA interna
openssl req -new -newkey ed25519 -nodes -keyout svcA.key -out svcA.csr \
    -subj "/CN=service-a.internal"
openssl x509 -req -in svcA.csr -CA ca.crt -CAkey ca.key -out svcA.crt -days 90

Certificati a vita breve (giorni, non anni) riducono il danno di una chiave compromessa: è il modello di SPIFFE/SPIRE, che emette identità effimere ai workload.

La configurazione (nginx)

Lato server, abilitare la verifica del certificato client è questione di tre direttive:

server {
    listen 443 ssl;
    ssl_certificate     /etc/tls/server.crt;
    ssl_certificate_key /etc/tls/server.key;
    ssl_client_certificate /etc/tls/ca.crt;   # la CA che firma i client fidati
    ssl_verify_client on;                       # richiedi e verifica il cert del client
    location / {
        # passa l'identità del client all'applicazione
        proxy_set_header X-Client-CN $ssl_client_s_dn;
    }
}

Le due righe evidenziate trasformano un normale server TLS in un endpoint mTLS: ssl_verify_client on rifiuta chi non presenta un certificato valido firmato dalla CA indicata.

Il vero costo: gestire i certificati

mTLS è potente ma sposta il problema sulla gestione dei certificati. Con decine di servizi e certificati a vita breve, l’emissione e la rotazione manuale non sono praticabili. Per questo mTLS “su larga scala” vive quasi sempre dentro un service mesh (Istio, Linkerd) o un sistema come SPIRE, che emettono e ruotano i certificati automaticamente, trasparenti all’applicazione. Senza automazione, mTLS tra molti servizi diventa ingestibile — ed è l’errore più comune di chi lo adotta.

Lab

Con una CA di test e due servizi (o openssl s_server/s_client):

Create una CA, un certificato server e un certificato client, tutti firmati dalla CA.
Avviate il server con ssl_verify_client on.
Connettetevi senza certificato client: deve fallire.
Connettetevi con il certificato client: deve riuscire, e il server deve vedere il CN.
Provate un certificato firmato da un’altra CA: deve essere rifiutato.

Domanda: se il traffico tra microservizi è già dentro un cluster privato, perché cifrarlo e autenticarlo con mTLS?

Perché "dentro il cluster" non significa "fidato". È proprio l'assunzione che il modello Zero Trust smonta: se un attaccante compromette un singolo pod o si inserisce nella rete interna (pensate all'ARP spoofing del capitolo 02), senza mTLS può leggere il traffico tra servizi e impersonarne uno, perché nulla verifica le identità. mTLS rende quel traffico illeggibile e ogni chiamata autenticata: anche chi entra nella rete non può né ascoltare né fingersi un altro servizio. La rete piatta e fidata è esattamente ciò che non vogliamo più dare per scontato.

Conclusione

mTLS estende TLS dall’autenticazione del solo server a quella reciproca: entrambe le parti provano chi sono con un certificato. È il modo in cui i servizi si fidano l’uno dell’altro senza affidarsi alla rete, e il mattone dell’architettura Zero Trust. Il prezzo è la gestione dei certificati, che su scala richiede automazione — un service mesh o SPIRE — altrimenti il rimedio diventa più oneroso del problema.

IPsec contro WireGuard

Tue, 22 Sep 2026 09:00:00 +0200

Perché conta

Nel capitolo su TLS abbiamo cifrato una singola connessione. Una VPN fa un passo più in là: cifra tutto il traffico IP tra due punti, creando un tunnel attraverso una rete non fidata. Serve a collegare due sedi (site-to-site) o a far entrare un lavoratore da remoto nella LAN — la minaccia T6 del threat model, dove serviva anche tracciare chi si collega.

Le due tecnologie dominanti sono agli antipodi per filosofia: IPsec è una suite completa e configurabile all’eccesso; WireGuard è una cinquantina di righe di concetti. Abbiamo già visto WireGuard in pratica; qui lo confrontiamo con IPsec per capire quando scegliere cosa.

IPsec: una suite, non un protocollo

IPsec non è un protocollo ma un insieme. Ha due modalità e due protocolli di protezione, e una negoziazione separata delle chiavi:

  flowchart TD
    IPsec --> IKE["IKEv2<br/>negozia le chiavi e la SA"]
    IPsec --> ESP["ESP<br/>cifra e autentica i pacchetti"]
    IPsec --> Modes["Modalità"]
    Modes --> Tunnel["Tunnel<br/>incapsula l'intero pacchetto IP<br/>(site-to-site)"]
    Modes --> Transport["Transport<br/>protegge solo il payload<br/>(host-to-host)"]

IKEv2 stabilisce la Security Association (SA): le due parti si autenticano (con chiavi precondivise o certificati) e concordano chiavi e algoritmi, con forward secrecy.
ESP è ciò che protegge davvero i pacchetti: li cifra e li autentica.
In modalità tunnel l’intero pacchetto IP originale viene incapsulato in uno nuovo: è quella usata per collegare due reti.

La forza di IPsec è la sua universalità: lo parlano router, firewall e sistemi operativi di ogni marca, ed è lo standard nelle interconnessioni aziendali. La debolezza è la complessità: decine di parametri da far combaciare tra i due lati, e un fallimento di negoziazione difficile da diagnosticare.

WireGuard: fare meno, meglio

WireGuard parte da un’idea opposta: niente negoziazione di algoritmi, niente opzioni. Usa un set fisso di primitive crittografiche moderne (Curve25519, ChaCha20-Poly1305, BLAKE2s). Se un domani una di queste si indebolisce, si cambia versione del protocollo, non si negozia.

L’autenticazione è semplicissima: ogni peer ha una coppia di chiavi, come SSH. Si conoscono per chiave pubblica. La configurazione di un lato sta in poche righe:

[Interface]
PrivateKey = <chiave privata locale>          # la mia identità
Address    = 10.9.0.1/24
ListenPort = 51820

[Peer]
PublicKey  = <chiave pubblica del peer>        # di chi mi fido
AllowedIPs = 10.9.0.2/32                        # quali IP accetto/instrado da questo peer
Endpoint   = peer.esempio.it:51820

Le due righe evidenziate sono il cuore del modello: la mia chiave privata definisce chi sono, la chiave pubblica del peer definisce di chi mi fido. AllowedIPs fa doppio lavoro: è insieme una regola di routing (quali IP mando nel tunnel) e di sicurezza (quali IP accetto da quel peer, una forma di cryptokey routing).

1
2

wg-quick up wg0          # attiva il tunnel
wg show                  # stato: handshake, byte trasferiti, ultimo contatto

Un dettaglio che conta per la sicurezza: WireGuard è silenzioso. Non risponde a chi non presenta una chiave valida, quindi dall’esterno la porta sembra chiusa. Un attaccante che fa uno scan non trova nulla a cui agganciarsi.

Il confronto

	IPsec	WireGuard
Natura	suite configurabile	protocollo minimale, opzioni fisse
Righe di codice (kernel)	~decine di migliaia	~4.000
Negoziazione	IKEv2, molti parametri	nessuna: primitive fisse
Autenticazione	PSK o certificati (PKI)	coppie di chiavi, stile SSH
Interoperabilità	universale (standard aziendale)	ottima tra sistemi WireGuard
Prestazioni	buone	generalmente migliori, meno overhead
Attraversamento NAT	può richiedere NAT-T	nativo, con keepalive
Diagnosi dei guasti	spesso complessa	`wg show` dice quasi tutto

Quando scegliere cosa

WireGuard per road warrior, collegamenti tra server, lab, qualunque caso in cui si controllano entrambi i lati. Più semplice significa meno errori di configurazione, e la superficie di codice ridotta è essa stessa un vantaggio di sicurezza.
IPsec quando serve interoperare con apparati che parlano solo IPsec (molti firewall e router aziendali), o dove policy e audit impongono certificati e algoritmi negoziabili.

La semplicità di WireGuard non è una scorciatoia di sicurezza: è una scelta di design. Meno codice e meno opzioni significano meno superficie per i bug e meno modi di configurare male. Ma IPsec resta insostituibile dove l’altro capo non è vostro.

Tracciare chi si collega (la minaccia T6)

Il threat model chiedeva di registrare gli accessi VPN. Con WireGuard, wg show espone per ogni peer l’ultimo handshake e i byte trasferiti; esportando questi dati (o i log del kernel) a un sistema centrale si ottiene la tracciabilità richiesta. Con IPsec, IKEv2 registra le SA negoziate. In entrambi i casi il punto è inoltrare quei dati a un log centralizzato, non lasciarli solo sul gateway.

Lab

Nel lab containerlab, due nodi che simulano due sedi separate da una rete “non fidata”:

Generate le coppie di chiavi WireGuard (wg genkey | tee priv | wg pubkey).
Configurate i due lati e attivate il tunnel con wg-quick.
Da un lato, ping l’IP interno dell’altro e catturate il traffico sulla rete intermedia: deve essere illeggibile (UDP cifrato).
wg show: osservate l’handshake e i contatori.

Domanda: perché WireGuard usa UDP e non TCP?

Perché incapsulare traffico TCP dentro un tunnel TCP crea il problema del "TCP meltdown": due controlli di congestione e due ritrasmissioni annidati che si combattono, con prestazioni che crollano quando la rete perde pacchetti. UDP non ha controllo di congestione né ritrasmissione, così il TCP interno gestisce da solo il suo recupero errori end-to-end, come se il tunnel non ci fosse. È lo stesso motivo per cui anche IPsec/ESP e la maggior parte delle VPN serie preferiscono UDP.

Conclusione

IPsec e WireGuard risolvono lo stesso problema con filosofie opposte: configurabilità universale contro minimalismo. Non c’è un vincitore assoluto: WireGuard dove controllate entrambi i capi, IPsec dove dovete parlare con il mondo. In entrambi i casi, un tunnel è sicuro solo quanto la gestione delle sue chiavi e il tracciamento di chi lo usa.

Abbiamo costruito difese per nove capitoli. Nel prossimo mettiamo tutto alla prova dalla parte di chi indaga: analizzare una cattura di pacchetti e ritrovare, dentro il traffico, gli attacchi che abbiamo studiato.

Prossimo nella serie: 10 · Analisi dei pacchetti con Wireshark · Torna alla roadmap

Sicurezza del DNS: DNSSEC e DoH

Tue, 08 Sep 2026 09:00:00 +0200

Perché conta

Nel capitolo su TLS abbiamo visto come proteggere una connessione. Ma prima di aprirla, il client chiede al DNS: “qual è l’IP di banca.it?”. Se un attaccante risponde al posto del DNS legittimo — minaccia T7 del threat model — manda il client su un IP che controlla lui. TLS su quel sito mostrerebbe un errore di certificato, certo, ma il DNS è il primo anello, e troppi attacchi partono da lì.

Il DNS classico ha due difetti indipendenti: non autentica le risposte (chiunque può falsificarle) e non le cifra (chiunque sulla rete le legge). Vanno risolti separatamente.

Il problema 1: autenticità — cache poisoning

Una query DNS esce con un ID di transazione a 16 bit e attende la risposta. Chi risponde per primo con l’ID giusto vince — anche un attaccante, se indovina l’ID prima del server vero. La risposta falsa viene messa in cache dal resolver, e da quel momento tutti quelli che usano quel resolver vengono mandati sull’IP sbagliato. È il cache poisoning.

  sequenceDiagram
    participant C as Client
    participant R as Resolver
    participant A as Attaccante
    participant S as Server DNS vero
    C->>R: banca.it ?
    R->>S: banca.it ? (txid 0x3f9a)
    A-->>R: banca.it = 6.6.6.6 (txid indovinato, arriva prima)
    Note over R: mette in cache la risposta falsa
    S->>R: banca.it = 1.2.3.4 (arriva dopo, scartata)
    R->>C: banca.it = 6.6.6.6

La soluzione: DNSSEC

DNSSEC firma le risposte DNS con la crittografia a chiave pubblica. Ogni zona firma i propri record; la zona superiore firma la chiave di quella inferiore, formando una catena di fiducia che parte dalla radice ., esattamente come la PKI di TLS parte dalle CA radice.

  flowchart TD
    Root[". (root)"] -->|firma la chiave di| IT[".it"]
    IT -->|firma la chiave di| Dom["banca.it"]
    Dom -->|firma i record| A["A = 1.2.3.4 (RRSIG)"]

Il resolver verifica le firme risalendo la catena. Una risposta falsificata non ha una firma valida e viene scartata: il cache poisoning fallisce perché l’attaccante non possiede la chiave privata della zona.

# chiedere i record DNSSEC e verificare la firma
dig banca.it +dnssec
# il flag "ad" (Authenticated Data) nella risposta indica validazione riuscita
dig @1.1.1.1 banca.it | grep -o 'flags:.*;'

Attenzione: DNSSEC autentica ma non cifra. Chiunque sulla rete vede ancora quali domini chiedete. Risolve il problema 1, non il problema 2.

Il problema 2: riservatezza — tutti leggono le query

Una query DNS classica viaggia in UDP, in chiaro, sulla porta 53. Chiunque sia sul percorso — il proprietario della rete Wi-Fi, il provider, un uomo nel mezzo — legge l’elenco dei siti che visitate, anche se poi vi collegate in HTTPS. E può ancora intercettarla e rispondere.

La soluzione: DoT e DoH

Due standard cifrano il trasporto del DNS dentro TLS:

	DoT (DNS over TLS)	DoH (DNS over HTTPS)
Porta	853 (dedicata)	443 (come il traffico web)
Visibilità	si distingue dal resto del traffico	indistinguibile dal normale HTTPS
Blocco	facile da bloccare (porta nota)	difficile: bloccarlo blocca il web
Uso tipico	resolver di rete, policy aziendali	browser, aggiramento della censura

# DoT verso un resolver pubblico
kdig -d @1.1.1.1 +tls banca.it

# DoH: una query DNS dentro una normale richiesta HTTPS
curl -s -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=banca.it&type=A'

Le due soluzioni sono complementari

È l’errore più comune: pensare che DoH “renda sicuro” il DNS. DoH cifra la query verso il resolver, ma se quel resolver non valida DNSSEC, può comunque ricevere e inoltrarvi una risposta falsa. E DNSSEC autentica, ma lascia la query visibile. La configurazione robusta usa entrambi: un resolver che valida DNSSEC, raggiunto via DoT/DoH.

Nel lab si costruisce con unbound:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"   # abilita la validazione DNSSEC
    # ... ascolto su localhost ...
forward-zone:
    name: "."
    forward-tls-upstream: yes                              # inoltra agli upstream via DoT
    forward-addr: 1.1.1.1@853

La prima riga evidenziata attiva la validazione DNSSEC (problema 1); la seconda cifra l’inoltro verso l’upstream con DoT (problema 2).

Lab

Nel lab containerlab, con un nodo resolver (unbound) e un nodo client:

Configurate unbound con validazione DNSSEC e upstream in DoT.
Da client, dig un dominio firmato DNSSEC e verificate il flag ad.
dig un dominio con firma deliberatamente rotta (ne esistono di test, es. dnssec-failed.org): il resolver deve rispondere SERVFAIL, non l’IP.
Catturate il traffico tra resolver e upstream: con DoT deve essere illeggibile (TLS sulla 853).

Domanda: perché un dominio con DNSSEC rotto dà SERVFAIL e non l'IP?

Perché la validazione è una scelta binaria: o la firma è valida, o la risposta non è fidata. Un resolver che valida DNSSEC, di fronte a una firma che non torna (scaduta, mancante, manomessa), non ha modo di sapere se è un errore di configurazione o un attacco in corso, quindi tratta la risposta come non attendibile e restituisce SERVFAIL. È un "fallire in sicurezza": meglio nessuna risposta che una risposta potenzialmente falsa. Lo svantaggio è che un errore di firma del gestore del dominio rende il sito irraggiungibile per chi valida — ed è successo a domini importanti.

Conclusione

Il DNS ha due problemi distinti: autenticità e riservatezza. DNSSEC firma (problema 1), DoT/DoH cifrano (problema 2). Confonderli porta a configurazioni che sembrano sicure e non lo sono. La difesa completa li combina: resolver che valida DNSSEC, raggiunto con trasporto cifrato.

Fin qui abbiamo difeso riservatezza, integrità e autenticità. Resta la terza gamba della sicurezza: la disponibilità. Nel prossimo capitolo l’attacco che la prende di mira: il DDoS.

Prossimo nella serie: 08 · Anatomia di un DDoS · Torna alla roadmap

TLS 1.3 in profondità

Tue, 01 Sep 2026 09:00:00 +0200

Perché conta

Tutti gli attacchi dei capitoli precedenti — ARP spoofing, DHCP rogue, uomo nel mezzo — hanno lo stesso punto debole come bersaglio: il traffico in chiaro. TLS è la risposta. Risolve un problema che sembra impossibile: due macchine che non si sono mai parlate devono accordarsi su una chiave segreta, mentre un attaccante registra ogni byte che si scambiano. E devono anche essere sicure di parlare con chi credono, non con l’uomo nel mezzo.

TLS 1.3 (RFC 8446, 2018) ha ripulito vent’anni di debolezze. Vediamo come funziona.

Il problema dello scambio di chiavi

La cifratura simmetrica è veloce ma richiede una chiave condivisa. Come la si concorda su un canale che l’attaccante ascolta? La risposta è lo scambio Diffie-Hellman, in TLS 1.3 nella variante su curve ellittiche (ECDHE).

L’idea, semplificata: client e server scelgono ciascuno un segreto privato ($a$ e $b$) e si scambiano un valore pubblico derivato. Grazie alla proprietà matematica dello scambio, entrambi calcolano lo stesso segreto condiviso $S$ senza mai trasmetterlo:

$$ S = g^{ab} \bmod p $$

L’attaccante vede passare $g^a$ e $g^b$, ma per ricavare $S$ dovrebbe risolvere il problema del logaritmo discreto, computazionalmente proibitivo con i parametri usati. La chiave non viaggia mai sul filo: viene calcolata alle due estremità.

L’handshake TLS 1.3

La novità più visibile di TLS 1.3 è la velocità: l’handshake si completa in un solo giro (1-RTT), contro i due di TLS 1.2. Il client azzarda i parametri già nel primo messaggio.

  sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (versioni, cifrari, key_share g^a)
    Note over S: sceglie i parametri, calcola S = (g^a)^b
    S->>C: ServerHello (key_share g^b)
    S->>C: {Certificate, CertificateVerify, Finished} (già cifrati)
    Note over C: calcola S = (g^b)^a, verifica il certificato
    C->>S: {Finished} (cifrato)
    Note over C,S: canale cifrato stabilito in 1-RTT

Dal ServerHello in poi tutto è già cifrato, inclusi il certificato del server. In TLS 1.2 il certificato viaggiava in chiaro.

Autenticazione: la catena di certificati

Lo scambio ECDHE protegge dall’ascolto, ma non dall’uomo nel mezzo: un attaccante potrebbe fare un proprio scambio con il client fingendosi il server. Serve autenticazione, e la dà la PKI.

Il server presenta un certificato che lega il suo nome di dominio a una chiave pubblica, firmato da una Certificate Authority (CA). Il client verifica la firma risalendo la catena fino a una CA radice di cui si fida già (sono preinstallate nel sistema).

  flowchart TD
    Root["CA radice<br/>(preinstallata, fidata)"] -->|firma| Inter["CA intermedia"]
    Inter -->|firma| Leaf["Certificato del server<br/>esempio.it"]
    Leaf -.verificato dal.-> Client

In CertificateVerify il server firma l’handshake con la chiave privata corrispondente al certificato: prova di possedere la chiave, non solo di esibire il certificato. Un uomo nel mezzo non ha quella chiave privata, quindi non può produrre quella firma.

Due proprietà che contano

Forward secrecy. In TLS 1.3 ogni connessione usa una coppia ECDHE effimera, nuova ogni volta e cancellata dopo. Se un attaccante registra oggi il traffico cifrato e tra un anno ruba la chiave privata del server, non può decifrare quel traffico: la chiave di sessione non derivava da quella del server, ed è sparita. TLS 1.2 lo permetteva solo con i cifrari giusti; 1.3 lo rende obbligatorio.

Niente cifrari deboli. TLS 1.3 ha rimosso dalla negoziazione RC4, 3DES, MD5, lo scambio RSA statico e la rinegoziazione. Molti attacchi storici (BEAST, POODLE, downgrade) sfruttavano proprio quelle opzioni: toglierle dal protocollo le chiude per costruzione.

Vederlo nel lab

Con openssl si ispeziona un handshake reale:

# handshake completo verso un server, con dettagli
openssl s_client -connect esempio.it:443 -tls1_3

# guardare il certificato e la sua catena
openssl s_client -connect esempio.it:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Nel lab containerlab si può generare una CA di test, emettere un certificato per un server interno e osservare la verifica della catena, senza toccare internet.

La configurazione lato server

# solo TLS 1.2 e 1.3; niente versioni vecchie
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;         # in 1.3 la lista cifrari è già sicura
ssl_session_tickets off;               # i ticket possono indebolire la forward secrecy

Le due righe evidenziate sono il minimo: disattivare le versioni obsolete e lasciare a TLS 1.3 la scelta dei cifrari, che sono già tutti robusti.

Lab

Nel lab, create una CA di test (openssl req -x509 ...) ed emettete un certificato per un server interno.
Avviate un server TLS 1.3 (openssl s_server) e collegatevi con openssl s_client.
Osservate con quale key_share e cifrario si conclude l’handshake.
Provate a forzare -tls1_1: il server deve rifiutare.

Domanda: se tutto è cifrato, l'IDS del capitolo 05 serve ancora a qualcosa?

Sì, ma vede meno. Con TLS, un IDS passivo non legge il contenuto HTTP: vede solo i metadati — indirizzi IP, dimensioni e tempi dei pacchetti, e il nome del server nell'estensione SNI (in chiaro anche in TLS 1.3, salvo ECH). Può ancora rilevare schemi (scan, beaconing di malware, destinazioni note come malevole), ma non il payload. Per ispezionare il contenuto cifrato servirebbe la decifratura TLS (un proxy che termina e ri-origina la connessione), che però rompe la forward secrecy end-to-end e introduce un punto in cui il traffico è di nuovo in chiaro. È un compromesso di sicurezza serio, non una funzione da attivare a cuor leggero.

Conclusione

TLS 1.3 risolve due problemi distinti con due meccanismi distinti: ECDHE per la segretezza (nessuno ascolta), la PKI per l’autenticazione (parli con chi credi). La forward secrecy obbligatoria e l’eliminazione dei cifrari deboli chiudono per costruzione gli attacchi che affliggevano le versioni precedenti.

TLS protegge il trasporto. Ma prima ancora di aprire una connessione, il client deve sapere quale IP ha esempio.it: lo chiede al DNS. E il DNS, per impostazione predefinita, è in chiaro e senza autenticazione — il prossimo bersaglio.

Prossimo nella serie: 07 · Sicurezza del DNS: DNSSEC e DoH · Torna alla roadmap