TLS, OpenVPN e sicurezza multilivello

di
📋 Obiettivi di apprendimento
✓Descrivere l’architettura di TLS distinguendo Handshake Protocol e Record Protocol, e spiegare la Perfect Forward Secrecy
✓Confrontare TLS 1.2 e TLS 1.3 indicando le differenze principali in termini di prestazioni e sicurezza
✓Spiegare come OpenVPN e WireGuard usano TLS/crittografia moderna per creare tunnel VPN a livello applicativo
✓Classificare i protocolli di sicurezza per livello OSI e spiegare come si combinano in scenari reali (sicurezza multilivello)
📄
Slides
TLS, OpenVPN, WireGuard e sicurezza multilivello

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:

Livello OSI
Protocollo
Cosa protegge
3 — Network
IPsec
Tutti i pacchetti IP — tutti i protocolli superiori ne beneficiano automaticamente
4+7 — Tra Trasporto e Applicativo
TLS
Una specifica sessione applicativa (HTTPS, SMTP, IMAP, API REST)
7 — Applicativo
PGP, Kerberos
Il contenuto del messaggio o l’identità dell’utente — indipendente dal canale
📌 Il principio chiave della sicurezza a strati

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. Ma l’opposto non vale: TLS protegge solo la sessione HTTP specifica, non l’intero traffico IP della macchina.

TLS — Transport Layer Security

TLS (Transport Layer Security) è il protocollo crittografico che oggi garantisce la sicurezza della stragrande maggioranza delle comunicazioni su Internet. Quando un browser mostra il lucchetto accanto all’indirizzo di un sito, quando invii un’email tramite un server moderno, quando un’app comunica con un’API REST — nella quasi totalità dei casi è TLS che protegge lo scambio.

Collocazione di TLS nello stack OSI
7 — Applicativo  (HTTP, SMTP, FTP…)
TLS — si inserisce qui, tra Trasporto e Applicativo
4 — Trasporto  (TCP)
3 — Network  (IP)

TLS non sostituisce TCP ma si inserisce sopra di esso, creando un canale sicuro punto-punto tra due applicazioni specifiche.

I tre obiettivi fondamentali di TLS

🔒 Riservatezza

I dati vengono cifrati con algoritmi simmetrici (AES, ChaCha20). Anche intercettando tutto il traffico, il contenuto è illeggibile.

✅ Integrità

Ogni messaggio include un codice di autenticazione (MAC/AEAD). Qualsiasi alterazione — anche di un bit — causa il fallimento della verifica.

🪪 Autenticazione

Il client verifica l’identità del server tramite certificato digitale X.509 firmato da una CA fidata. Opzionalmente anche il server autentica il client.

TLS Handshake Protocol — la fase di negoziazione

L’handshake TLS è la fase iniziale della comunicazione. 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.

TLS 1.2 — handshake in 2 round trip (2-RTT)

TLS 1.2 Handshake — sequenza messaggi
Client Hello
versione TLS, cipher suites, client random
→
Server riceve
Client riceve
←
Server Hello + Certificato + Server Hello Done
cipher scelto, server random, certificato X.509
Client Key Exchange + Change Cipher Spec + Finished
pre-master secret cifrato, conferma parametri
→
Server riceve
Sessione stabilita ✅
←
Change Cipher Spec + Finished
conferma parametri — ora entrambi usano la chiave di sessione
TLS 1.2 richiede 2 round trip prima di poter inviare dati applicativi — una latenza visibile specialmente su reti mobili.

TLS 1.3 — handshake in 1 round trip (1-RTT)

TLS 1.3 (RFC 8446, 2018) ha semplificato radicalmente l’handshake riducendolo a un solo round trip — dimezzando la latenza di connessione. È lo standard attuale.

TLS 1.3 Handshake — sequenza messaggi (1-RTT)
Client Hello
versione TLS, cipher suites, key share DH, client random
→
Server riceve
Sessione stabilita ✅
←
Server Hello + Certificato + Finished
tutto in un unico messaggio — il server calcola già la chiave di sessione
In TLS 1.3 il client include già i parametri DH nel primo messaggio. Il server può calcolare la chiave di sessione immediatamente e rispondere con dati cifrati dal primo round trip.
TLS 1.2 vs TLS 1.3 — confronto
AspettoTLS 1.2TLS 1.3
Latenza handshake2-RTT1-RTT (0-RTT per resumption)
Cipher suites supportatiMolti, inclusi obsoleti (RC4, MD5)Solo 5 — tutti sicuri e moderni
Perfect Forward SecrecyOpzionaleObbligatoria
Scambio chiaviRSA o DH (incluso statico)Solo ECDHE (sempre forward secrecy)
Cifratura handshakeParziale (molti campi in chiaro)Quasi tutto cifrato, incluso il certificato

TLS Record Protocol — la protezione dei dati

Terminato l’handshake, entra in funzione il TLS Record Protocol, che si occupa della protezione concreta di ogni messaggio scambiato tra le due applicazioni.

Cosa succede a ogni messaggio applicativo
1

I dati applicativi vengono suddivisi in blocchi di dimensione massima ~16 KB

2

Viene calcolato il codice di autenticazione del messaggio (AEAD: Authenticated Encryption with Associated Data)

3

Il blocco viene cifrato con la chiave simmetrica di sessione (AES-GCM o ChaCha20-Poly1305)

4

Viene aggiunta l’intestazione TLS Record e il messaggio viene inviato tramite TCP

!

Al destinatario avviene il processo inverso. Se anche un solo bit è stato alterato in transito, la verifica AEAD fallisce e la connessione viene terminata

Perfect Forward Secrecy in TLS

📌 Perfect Forward Secrecy (PFS)

In TLS 1.2 era possibile usare RSA per lo scambio delle chiavi: la chiave di sessione veniva cifrata con la chiave pubblica del server e inviata al client. Se un attaccante registrava tutte le comunicazioni cifrate e in futuro riusciva a ottenere la chiave privata del server, poteva decifrare tutto il traffico passato.

Con PFS (obbligatoria in TLS 1.3), le chiavi di sessione vengono generate con ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): parametri temporanei che non vengono mai salvati. Anche compromettendo la chiave privata del server in futuro, le sessioni passate restano indecifrabili perché le chiavi temporanee usate non esistono più.

OpenVPN — VPN a livello applicativo

OpenVPN è una soluzione VPN open source che usa TLS per creare tunnel sicuri. A differenza di IPsec — che opera nel kernel del sistema operativo — OpenVPN opera nello spazio utente tramite un’interfaccia di rete virtuale (tun o tap).

⚠️ Correzione rispetto a descrizioni comuni

OpenVPN viene spesso descritto come un protocollo “di livello applicativo”. È più preciso dire che opera tra il livello Trasporto e il livello Network: usa TLS (livello tra Trasporto e Applicativo) per la negoziazione e la cifratura, ma crea un’interfaccia tun virtuale che opera a livello 3, instradando pacchetti IP attraverso il tunnel. È la sicurezza di TLS applicata al tunneling di rete.

✅ Vantaggi di OpenVPN
▸Funziona su qualsiasi porta TCP o UDP — inclusa la porta 443 di HTTPS. Difficilissimo da bloccare con firewall
▸Configurazione flessibile e molto documentata
▸Supporta certificati digitali X.509 per autenticazione
▸Ampiamente usato sia in ambito aziendale che nei servizi VPN commerciali
⚠️ Limiti di OpenVPN
▸Latenza superiore a IPsec e WireGuard (opera nello spazio utente)
▸Codebase ampia (~70.000 righe) — più difficile da auditare
▸Richiede installazione di client software dedicato

WireGuard — la nuova generazione

WireGuard è un protocollo VPN moderno, progettato con un obiettivo preciso: semplicità massima e prestazioni elevate. Integrato nel kernel Linux dal 2020 e in Windows/macOS dal 2021, sta rapidamente diventando lo standard per le VPN ad alte prestazioni.

WireGuard — caratteristiche principali
Codebase ~4.000 righe di codice (vs ~70.000 di OpenVPN) — più facile da verificare e auditare
Crittografia Curve25519 (ECDH), ChaCha20-Poly1305, BLAKE2 — algoritmi moderni, nessuna negoziazione
Protocollo UDP soltanto — ottimizzato per prestazioni, gestisce la riconnessione automaticamente
Configurazione Estrema semplicità: chiavi pubbliche/private + indirizzo peer — simile a SSH
Prestazioni Opera nel kernel — throughput 3-4x superiore a OpenVPN, latenza vicina a IPsec
Confronto tra le tre soluzioni VPN principali
AspettoIPsecOpenVPNWireGuard
Livello OSINetwork (L3)Tra L3 e L7Network (L3, kernel)
Protocollo transportESP/AH (IP 50/51)TCP o UDPSolo UDP
Complessità config.AltaMediaBassa
PrestazioniOttimeMedieOttime
Integrazione Cisco IOS✅ Nativa❌ Non nativa❌ Non nativa
Uso tipicoEnterprise, Cisco, FortiGateVPN commerciali, PMILinux, cloud, nuovi servizi VPN

Sicurezza a livello Applicativo — PGP e Kerberos

Al livello applicativo la protezione viene integrata direttamente nel protocollo o nell’applicazione stessa, indipendentemente dal canale di trasmissione.

PGP — Pretty Good Privacy

Usato per proteggere messaggi di posta elettronica e file. A differenza di TLS o IPsec, PGP non protegge il canale di comunicazione ma il contenuto del messaggio stesso.

Il testo viene cifrato con la chiave pubblica del destinatario prima dell’invio. Può essere decifrato solo dal destinatario con la sua chiave privata — indipendentemente dal server di posta usato.
Usato in: ProtonMail, firma di pacchetti software, GPG su Linux
Kerberos — autenticazione distribuita

Kerberos non cifra il traffico ma gestisce l’autenticazione sicura in ambienti distribuiti. Si basa su un sistema di ticket rilasciati da un KDC (Key Distribution Center).

Un utente si autentica una sola volta con il KDC e riceve un ticket che gli permette di accedere a vari servizi senza reinserire la password — il fondamento del Single Sign-On aziendale.
Usato in: Windows Active Directory, MIT Kerberos, ambienti enterprise

Sicurezza multilivello — visione d’insieme

La sicurezza moderna non è mai affidata a un singolo meccanismo. Nella realtà i diversi livelli di protezione coesistono e si completano. Ecco come si presentano in uno scenario aziendale tipico:

Scenario: dipendente in smart working che accede al gestionale aziendale
L3
IPsec VPN Cifra tutto il traffico tra il laptop del dipendente e il gateway aziendale — la rete aziendale è estesa fino a casa
TLS
HTTPS Il browser usa TLS per cifrare la sessione con il gestionale — anche se qualcuno fosse dentro la rete aziendale, non potrebbe leggere i dati
L7
Kerberos/SSO Il gestionale verifica l’identità del dipendente tramite Active Directory con Kerberos — autenticazione sicura senza password in chiaro
L7
PGP (email) I documenti riservati allegati alle email vengono firmati digitalmente con PGP — protezione del contenuto indipendente dal canale
Risultato: anche se un attaccante riuscisse a violare un livello, gli altri restano intatti. IPsec protegge il canale, TLS protegge la sessione applicativa, Kerberos protegge l’identità, PGP protegge i contenuti.
Riepilogo — sicurezza per livello OSI
Livello OSIProtocollo/TecnicaCosa proteggeEsempi d’uso
3 — NetworkIPsec (AH, ESP)Tutti i pacchetti IP — tutti i livelli superioriVPN Site-to-Site, Remote Access aziendale
Tra 4 e 7TLS / SSLUna specifica sessione applicativaHTTPS, SMTPS, API REST, OpenVPN
7 — ApplicativoPGP / GPGIl contenuto del singolo messaggioEmail cifrate, firma documenti
7 — ApplicativoKerberosL’identità dell’utente — non il trafficoActive Directory, SSO aziendale
📌 Riepilogo — Punti chiave
  • TLS opera tra il livello Trasporto e quello Applicativo: protegge una specifica sessione, non tutto il traffico IP come IPsec
  • TLS 1.3 vs TLS 1.2: handshake in 1-RTT invece di 2-RTT, PFS obbligatoria, solo cipher suite sicuri, handshake quasi completamente cifrato
  • OpenVPN usa TLS per cifrare un tunnel VPN operando nello spazio utente tramite interfaccia tun; WireGuard opera nel kernel con crittografia moderna, ~4.000 righe di codice
  • PGP protegge il contenuto del messaggio indipendentemente dal canale; Kerberos gestisce l’autenticazione distribuita tramite ticket — non cifra il traffico
  • La sicurezza moderna è multilivello: IPsec protegge il canale di rete, TLS protegge la sessione applicativa, Kerberos autentica l’identità, PGP protegge i contenuti — livelli complementari e non sostitutivi

Lascia un commento