TLS, OpenVPN e sicurezza multilivello
Dallo stack Network all'applicativo: come TLS protegge la sessione, come OpenVPN e WireGuard creano tunnel VPN moderni e come combinare IPsec, TLS, Kerberos e PGP in un'architettura di difesa a strati completa.
1. Sicurezza oltre il livello Network
Nelle lezioni precedenti abbiamo studiato come IPsec protegga il traffico al livello Network (livello 3 OSI), garantendo riservatezza e integrità di tutti i pacchetti IP indipendentemente dall'applicazione. Ma la sicurezza delle comunicazioni non si realizza solo a questo livello. Esistono protocolli che proteggono le comunicazioni a livelli superiori dello stack OSI, ognuno con caratteristiche, ambiti di applicazione e modelli di fiducia diversi.
Se un protocollo di livello inferiore protegge il traffico, tutti i protocolli di livello superiore che viaggiano su di esso beneficiano automaticamente di quella protezione. L'opposto non vale: TLS protegge solo la sessione HTTP specifica, non l'intero traffico IP della macchina.
| Livello OSI | Protocollo | Cosa protegge | Modello di fiducia |
|---|---|---|---|
| 3 — Network | IPsec | Tutti i pacchetti IP | Gateway-to-gateway, host-to-gateway |
| 4+7 — Trasporto/App | TLS | Una singola sessione (HTTPS, SMTP...) | Certificati X.509 + CA pubbliche |
| 7 — Applicativo | PGP / Kerberos | Contenuto messaggio o identità utente | Rete di fiducia / KDC aziendale |
Protezione totale
Tutto il traffico IP della macchina è cifrato, anche ping e DNS se policy lo prevede.
Protezione selettiva
Solo l'app che usa TLS (browser, mail client) è protetta. Altro traffico resta in chiaro.
Protezione end-to-content
Il dato resta protetto anche se salvato su disco o inoltrato su canali non sicuri.
Nel lab, attivate Wireshark mentre navigate su https://didattica.scuola.local. Notate che vedete TCP + Client Hello in chiaro, poi tutto diventa Application Data cifrato. Ora attivate IPsec tra due PC del lab: tutto il traffico, anche il ping, appare come ESP. Questo rende tangibile la differenza L3 vs L4+7.
2. TLS – Transport Layer Security
TLS è il protocollo crittografico che oggi garantisce la sicurezza della stragrande maggioranza delle comunicazioni su Internet. Lucchetto del browser, email moderna, app che dialoga con API REST – è quasi sempre TLS.
TLS non sostituisce TCP ma si inserisce sopra di esso, creando un canale sicuro punto-punto tra due applicazioni specifiche. Opera tra Trasporto e Applicativo: non protegge tutto il traffico IP come IPsec.
🔒 Riservatezza
Dati cifrati con AES-GCM o ChaCha20-Poly1305. Intercettare tutto il traffico resta inutile.
✅ Integrità
AEAD: ogni messaggio ha tag di autenticazione. Alterare 1 bit → connessione abortita.
🪪 Autenticazione
Client verifica server via X.509 + CA. Opzionale mTLS per autenticazione client.
Se ti chiedono “TLS a che livello OSI sta?” non dire solo “livello 4” o “livello 7”. Rispondi: “Si colloca tra Trasporto e Applicativo, sopra TCP, e protegge una specifica sessione applicativa”. Così dimostri di aver capito anche la differenza con IPsec. Bonus: cita Record Protocol e Handshake Protocol.
Confondere TLS con HTTPS. HTTPS = HTTP sopra TLS. TLS è il livello di sicurezza, HTTP è l'applicazione. Allo stesso modo SMTPS = SMTP sopra TLS. Non chiamare tutto “SSL” – SSL è deprecato dal 2015.
3. Handshake TLS 1.2 vs TLS 1.3 – da 2-RTT a 1-RTT
L'handshake TLS è la fase iniziale: client e server si presentano, si riconoscono e concordano come proteggere i dati. È il momento più critico: da qui dipende l'intera sicurezza della sessione successiva gestita dal Record Protocol.
TLS 1.2 – 2 round trip
Client Hello (versione, cipher list, random) → Server Hello + Certificato + Server Hello Done → Client Key Exchange + ChangeCipherSpec + Finished → Server ChangeCipherSpec + Finished. Servono 2 RTT prima di inviare dati applicativi. Latenza visibile su 4G/5G.
TLS 1.3 – 1-RTT, PFS obbligatoria, tutto quasi cifrato
TLS 1.3 (RFC 8446, 2018) semplifica radicalmente l'handshake: il client invia già nel primo messaggio il suo key share ECDHE. Il server calcola subito la chiave di sessione e risponde con tutto in un colpo solo, già cifrato.
| Aspetto | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Latenza | 2-RTT | 1-RTT, 0-RTT resumption |
| Cipher suite | Molte, anche obsolete (RC4, MD5) | Solo 5 sicure, AEAD obbligatorio |
| PFS | Opzionale | Obbligatoria (solo ECDHE) |
| Key exchange | RSA o DH statico possibile | Solo ECDHE ephemeral |
| Privacy handshake | Certificato in chiaro | Quasi tutto cifrato, cert cifrato |
Su due VM Debian, abilitate Apache con TLS 1.2 only e poi TLS 1.3 only. Con curl -w time_handshake misurate il tempo. Su rete con 100ms RTT, TLS 1.3 risparmia ~130ms per ogni nuova connessione: su sito con 6 connessioni, è ~0.8s percepiti dall'utente.
4. Record Protocol e Perfect Forward Secrecy
Terminato l'handshake, entra in funzione il TLS Record Protocol: suddivide i dati applicativi in blocchi max ~16KB, calcola tag AEAD, cifra con chiave simmetrica di sessione, aggiunge header Record e invia via TCP. Al destinatario processo inverso: se anche 1 bit è alterato, AEAD fallisce e connessione abortita.
Perfect Forward Secrecy: anche se in futuro la chiave privata del server viene compromessa, le sessioni passate restano indecifrabili perché le chiavi ephemeral usate per ECDHE non esistono più e non sono mai state salvate.
Senza PFS – vulnerabile a posteriori
Pre-master secret cifrato con chiave pubblica server e inviato. Se attaccante registra traffico e poi ottiene chiave privata, decifra tutto il passato.
Con PFS – sicuro nel tempo
Chiavi temporanee Curve25519 generate on-the-fly, mai salvate. Compromissione futura non retroattiva. Obbligatoria in TLS 1.3.
Per ricordare AEAD: “Cifra e autentica insieme”. In TLS 1.3 si usano solo AEAD (AES-GCM, ChaCha20-Poly1305). Non esiste più MAC-then-Encrypt separato come in TLS 1.0. Se all'esame vi chiedono perché TLS 1.3 è più sicuro, citate: 1) meno cipher = meno errori, 2) PFS obbligatoria, 3) handshake cifrato, 4) rimozione funzionalità pericolose (compression, renegotiation).
5. OpenVPN e WireGuard – VPN moderne a confronto
OpenVPN è open source, usa TLS per creare tunnel, opera in userspace tramite interfaccia tun/tap virtuale L3. WireGuard è new-gen, ~4.000 righe di codice, kernel-space, crittografia moderna fissa, UDP only.
OpenVPN viene spesso descritto come “protocollo di livello applicativo”. È più preciso dire che opera tra L3 e L7: usa TLS (tra Trasporto e Applicativo) per negoziazione e cifratura, ma crea interfaccia tun L3 che instrada pacchetti IP attraverso il tunnel. È la sicurezza di TLS applicata al tunneling di rete.
✅ Vantaggi
Funziona su qualsiasi porta TCP/UDP inclusa 443 HTTPS → difficile da bloccare. Supporta X.509, molto documentato, usato da PMI e commerciali.
⚠️ Trade-off
Latenza superiore (userspace), codebase ampia difficile da auditare, richiede client dedicato. Niente integrazione nativa Cisco IOS.
✅ Vantaggi
Kernel-space: throughput 3-4x OpenVPN, latenza vicina a IPsec. Crittografia fissa: Curve25519, ChaCha20-Poly1305, BLAKE2. Configurazione semplice come SSH.
🧠 Caratteristiche
Solo UDP, roaming automatico (ideale mobile), no negoziazione cipher, integrato nel kernel Linux dal 2020. Perfetto per cloud e Linux.
| Aspetto | IPsec | OpenVPN | WireGuard |
|---|---|---|---|
| Livello OSI | Network L3 | Tra L3 e L7 (tun + TLS) | Network L3, kernel |
| Transport | ESP/AH (IP 50/51) | TCP o UDP | Solo UDP |
| Complessità | Alta | Media | Bassa |
| Prestazioni | Ottime | Medie | Ottime, 3-4x OpenVPN |
| Cisco IOS nativa | ✅ Sì | ❌ No | ❌ No |
| Uso tipico | Enterprise, Site-to-Site | Commerciale, PMI, bypass firewall | Linux, cloud, servizi new-gen |
Configurate due tunnel tra le stesse VM: uno OpenVPN UDP e uno WireGuard. Lanciate iperf3. In genere WireGuard raggiunge 800-900 Mbps vs 200-300 Mbps di OpenVPN su stessa CPU, a pari latenza inferiore di 2-3ms. Annotate i risultati e discutete perché kernel vs userspace fa la differenza.
6. Sicurezza a livello Applicativo – PGP e Kerberos
Al livello applicativo la protezione è integrata direttamente nell'app, indipendente dal canale.
Pretty Good Privacy
Protegge il messaggio stesso, non il canale. Testo cifrato con chiave pubblica destinatario prima dell'invio. Decifrabile solo da destinatario. Usato in ProtonMail, firma pacchetti Linux, backup cifrati.
Autenticazione distribuita
Non cifra il traffico ma gestisce autenticazione via ticket KDC. Login una volta, ticket per tutti i servizi → base del SSO aziendale. Usato in Active Directory Windows.
PGP protegge il contenuto del messaggio (confidenzialità persistente), Kerberos protegge l'identità dell'utente (autenticazione distribuita). Non sono sostituti di TLS/IPsec, ma livelli complementari.
Pensare che Kerberos “cifri il traffico”. Falso: Kerberos autentica e distribuisce chiavi di sessione; l'eventuale cifratura è delegata ad altri protocolli (es. LDAP + Kerberos non cifra LDAP di default).
7. Sicurezza multilivello – visione d'insieme e scenario reale
La sicurezza moderna non è mai affidata a un singolo meccanismo. I diversi livelli coesistono e si completano.
| Livello OSI | Protocollo | Cosa protegge | Esempi d'uso |
|---|---|---|---|
| 3 — Network | IPsec (AH, ESP) | Tutti i pacchetti IP | VPN Site-to-Site, Remote Access |
| Tra 4 e 7 | TLS / SSL | Una sessione applicativa | HTTPS, SMTPS, API, OpenVPN |
| 7 — Applicativo | PGP / GPG | Contenuto messaggio | Email cifrate, firma documenti |
| 7 — Applicativo | Kerberos | Identità utente | AD, SSO aziendale |
Un equivoco frequente: “sicuro = VPN”. In realtà VPN protegge il canale tra endpoint previsti dalla configurazione, HTTPS protegge la sessione browser-server via TLS. Se sei in VPN aziendale ma visiti http senza TLS, il traffico tra gateway aziendale e server finale è in chiaro su Internet! Viceversa, HTTPS senza VPN protegge solo quell'app, non tutto il traffico. Domanda per voi: se utente è in VPN, perché browser serve ancora HTTPS? Risposta: VPN protegge fino al gateway, HTTPS protegge end-to-end fino al server web anche oltre il perimetro aziendale, e aggiunge autenticazione del server via certificato pubblico globale, non solo aziendale.
Protegge il tunnel
Tra laptop e gateway VPN. Utile per estendere rete aziendale a casa, bypass NAT, protezione su Wi-Fi pubblico.
Protegge l'app
Tra browser e server web, ovunque sia. Garantisce certificato globale, PFS, cifratura AEAD. Necessario anche dentro VPN.
8. Verifica / Esercizio
🔬 Attività di verifica – progetta la sicurezza multilivello
Sei consulente per una PMI con 30 dipendenti, metà in smart working. Hanno gestionale web interno, email, e documenti riservati. Devi proporre stack di sicurezza a livelli.
- Disegna stack OSI indicando per ogni livello quale protocollo/tecnologia useresti (IPsec site-to-site? OpenVPN/WireGuard remote access? TLS? Kerberos? PGP?). Giustifica scelte in tabella.
- Spiega con esempio concreto perché TLS 1.3 è preferibile a TLS 1.2 per il gestionale: cita 1-RTT, PFS, cipher suite, privacy certificato.
- Configura (su carta o VM) un server OpenVPN su porta 443 TCP: spiega perché questa porta aiuta a bypassare firewall alberghieri e quali sono trade-off vs UDP 1194.
- Scenario attacco: un attaccante registra 1 anno di traffico TLS 1.2 con RSA key exchange e poi ruba chiave privata server. Cosa può fare? E con TLS 1.3 ECDHE? Collega a PFS.
1) Stack proposto: L3: IPsec Site-to-Site tra sede e AWS + WireGuard per smart working (prestazioni, roaming). Tra L4-L7: TLS 1.3 obbligatorio su gestionale e reverse proxy, certificati Let's Encrypt, HSTS. L7: Kerberos via Azure AD/AD on-prem per SSO gestionale, MFA. PGP/GPG per email con allegati riservati e firma release software. Risultato: se VPN WireGuard cade, TLS resta; se AD compromesso, PGP mantiene confidenzialità documenti già cifrati.
2) TLS 1.3 meglio: 1-RTT = login più rapido, 0-RTT per resumption, solo 5 cipher AEAD → meno superficie attacco, PFS obbligatoria → nessun rischio decifratura retroattiva, cert cifrato → privacy. Su mobile differenza percepita ~30%.
3) OpenVPN su 443 TCP: Molti hotel bloccano UDP e porte non 80/443. TCP 443 passa come HTTPS. Trade-off: TCP over TCP = meltdown (ritrasmissioni doppie) → throughput inferiore e latenza variabile; meglio UDP se rete permette. Config: port 443 proto tcp + masquerading firewall.
4) Attacco registrazione: Con TLS 1.2 RSA, pre-master secret cifrato con chiave pubblica server; recuperando chiave privata, attaccante decifra pre-master → deriva chiavi sessione → legge tutto il passato. Con TLS 1.3 ECDHE, chiavi ephemeral non salvate, anche con chiave privata futura non si deriva session key passata → PFS garantita. È esattamente perché PFS è obbligatoria ora.
9. Riepilogo e concetti chiave
📚 Prossimo passo – Modulo completato!
Hai concluso il Modulo 3 sulla sicurezza perimetrale e VPN! Ora sai distinguere firewall stateless/stateful, NGFW/UTM, ACL standard ed estese, DMZ/NAT, IPsec e TLS/OpenVPN/WireGuard. Nel prossimo modulo approfondiremo hardening e incident response. Ripassa la tabella OSI vs protocolli di sicurezza: sarà domanda ricorrente alla maturità.