TLS/SSL: handshake, cipher suite e vulnerabilità da trovare in pentest

TLS è il protocollo che cifra la maggior parte del traffico di rete moderno. Capire cos’è TLS e come funziona l’handshake, la negoziazione dei cipher suite, e la gestione dei certificati è fondamentale per chi fa pentesting: misconfigurazioni TLS sono tra le vulnerabilità più diffuse nelle reti enterprise, e attacchi come BEAST, POODLE, Heartbleed, e downgrade verso SSL sono vettori reali che portano a intercettazione di dati e compromissione di sessioni.

Cos’è TLS #

TLS (Transport Layer Security) è il successore di SSL (Secure Sockets Layer). Fornisce confidenzialità, integrità, e autenticazione per le comunicazioni su rete. Opera sopra TCP (livello 4) e sotto i protocolli applicativi (livello 7).

Cronologia delle versioni:

SSL è morto da anni. TLS 1.0 e 1.1 sono ufficialmente deprecati. TLS 1.2 è ancora ampiamente usato ma richiede configurazione attenta. TLS 1.3 è il gold standard attuale.

Come funziona TLS #

Il TLS Handshake (TLS 1.2) #

L’handshake TLS 1.2 stabilisce i parametri crittografici e autentica il server (e opzionalmente il client):

Client                              Server
  |                                    |
  |--- ClientHello -----------------> |  Versioni, cipher suites, random
  |                                    |
  |<-- ServerHello ------------------- |  Versione scelta, cipher suite, random
  |<-- Certificate ------------------- |  Certificato X.509 del server
  |<-- ServerHelloDone --------------- |
  |                                    |
  |--- ClientKeyExchange -----------> |  Pre-master secret (cifrato o DH)
  |--- ChangeCipherSpec ------------> |  "Passo alla cifratura"
  |--- Finished -------------------> |  Hash di tutto l'handshake cifrato
  |                                    |
  |<-- ChangeCipherSpec --------------- |
  |<-- Finished ---------------------- |
  |                                    |
  |   ===== SESSIONE CIFRATA =====   |

Il TLS 1.3 Handshake #

TLS 1.3 riduce l’handshake da 2 RTT a 1 RTT (o 0 RTT per sessioni ripristinate):

Client                              Server
  |                                    |
  |--- ClientHello -----------------> |  Versione, key share, cipher suites
  |    (include key_share)             |
  |                                    |
  |<-- ServerHello ------------------- |  Key share del server
  |<-- {EncryptedExtensions} --------- |  Cifrato già da qui
  |<-- {Certificate} ----------------- |
  |<-- {CertificateVerify} ----------- |
  |<-- {Finished} -------------------- |
  |                                    |
  |--- {Finished} -----------------> |
  |                                    |
  |   ===== SESSIONE CIFRATA =====   |

Differenze chiave di TLS 1.3:

• Eliminati algoritmi deboli: RSA key exchange, CBC mode, RC4, MD5, SHA-1
• Forward Secrecy obbligatoria (solo ECDHE e DHE)
• Handshake più veloce e meno dati in chiaro
• 0-RTT per sessioni ripristinate (con limitazioni di sicurezza)

Cipher Suite #

Una cipher suite specifica gli algoritmi usati in una sessione TLS. Il formato in TLS 1.2:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 │     │      │        │    │     │
 │     │      │        │    │     └── Hash per MAC/HMAC
 │     │      │        │    └──────── Modalità di cifratura
 │     │      │        └───────────── Algoritmo di cifratura
 │     │      └────────────────────── Algoritmo per l'autenticazione del server
 │     └───────────────────────────── Algoritmo di key exchange
 └─────────────────────────────────── Protocollo

Cipher suite deboli da identificare e riportare:

Certificati X.509 e PKI #

Il server autentica la propria identità tramite un certificato X.509 firmato da una Certificate Authority (CA) fidata. Il certificato contiene:

• Subject: identificativo del server (CN, SAN)
• Issuer: CA che ha firmato il certificato
• Validity: periodo di validità
• Public Key: chiave pubblica del server
• SAN (Subject Alternative Names): domini e IP coperti dal certificato
• Signature: firma digitale della CA

Il client verifica:

1. La firma della CA (trust chain)
2. La validità temporale
3. Il CN/SAN corrisponde al hostname a cui si sta connettendo
4. Il certificato non è revocato (CRL/OCSP)

Dove viene usato TLS nelle reti #

TLS è ovunque il traffico deve essere protetto:

• HTTPS (HTTP + TLS): porta 443 — web browsing, API, web app
• SMTPS/IMAPS/POP3S: email cifrata
• FTPS: FTP su TLS
• LDAPS: directory queries cifrate
• RDPS: Remote Desktop Protocol su TLS
• Database: MySQL, PostgreSQL, MSSQL supportano TLS
• VPN: OpenVPN usa TLS per il canale di controllo
• Applicazioni custom: qualsiasi socket TCP può essere cifrato con TLS

TLS è anche la base di DTLS (Datagram TLS), la versione per UDP usata da WebRTC, QUIC, e alcuni VPN.

Perché TLS è importante in cybersecurity #

Una configurazione TLS errata può rendere inutile la cifratura. Un pentester che sa analizzare TLS può trovare:

• Versioni obsolete attive: SSL 3.0, TLS 1.0, TLS 1.1 — vulnerabili a downgrade
• Cipher suite deboli: RC4, 3DES, cipher senza forward secrecy
• Certificati problematici: scaduti, self-signed, CN errato, CA non fidata
• Vulnerabilità specifiche: Heartbleed, BEAST, POODLE, ROBOT, DROWN
• Configurazioni che permettono SSL stripping: HTTP non rediretto, HSTS assente

Per il protocollo TCP su cui TLS opera, vedi TCP. Per le VPN basate su TLS, vedi IPSec.

TLS in un engagement di pentesting #

Enumerazione TLS con testssl.sh #

testssl.sh è lo strumento più completo per l’analisi della configurazione TLS:

# Installazione
git clone --depth 1 https://github.com/drwetter/testssl.sh.git

# Scan completo
./testssl.sh https://target.com

# Solo cipher suite
./testssl.sh --cipher-per-proto target.com:443

# Solo vulnerabilità
./testssl.sh --vulnerable target.com:443

# Output in JSON per integrazione
./testssl.sh --jsonfile output.json target.com:443

Output: versioni supportate, cipher suite per versione, certificato, e check automatico per BEAST, POODLE, Heartbleed, ROBOT, DROWN, Sweet32, LUCKY13, e molte altre.

Enumerazione con Nmap SSL scripts #

nmap -p 443 --script ssl-enum-ciphers target.com
nmap -p 443 --script ssl-cert target.com
nmap -p 443 --script ssl-heartbleed target.com
nmap -p 443 --script ssl-poodle target.com

Analisi manuale del certificato #

# Con OpenSSL
openssl s_client -connect target.com:443 -servername target.com

# Visualizzare il certificato
echo | openssl s_client -connect target.com:443 2>/dev/null | openssl x509 -text -noout

# Verificare la catena di trust
echo | openssl s_client -connect target.com:443 -showcerts 2>/dev/null

Forzare versioni specifiche #

# Testare se SSLv3 è accettato (POODLE)
openssl s_client -connect target.com:443 -ssl3

# Testare TLS 1.0 (BEAST)
openssl s_client -connect target.com:443 -tls1

# Testare TLS 1.1
openssl s_client -connect target.com:443 -tls1_1

# Testare cipher suite specifica
openssl s_client -connect target.com:443 -cipher RC4-MD5

Heartbleed (CVE-2014-0160) #

Heartbleed è probabilmente la vulnerabilità TLS più famosa. Permette di leggere fino a 64KB di memoria del server per ogni richiesta, rivelando potenzialmente chiavi private, password, e dati di sessione.

# Verifica con Nmap
nmap -p 443 --script ssl-heartbleed target.com

# Exploit con Metasploit
use auxiliary/scanner/ssl/openssl_heartbleed
set RHOSTS target.com
set VERBOSE true
run

Heartbleed è del 2014 ma ancora presente in ambienti con OpenSSL non aggiornato.

SSL Stripping #

In assenza di HSTS, un attaccante MITM può degradare le connessioni HTTPS a HTTP, intercettando il traffico in chiaro. Tool: sslstrip o mitmproxy:

# Setup con bettercap
bettercap -iface eth0
# Dentro bettercap:
net.probe on
arp.spoof on
https.proxy on
set https.proxy.sslstrip true

Downgrade Attack #

Se il server accetta TLS 1.0 o SSL 3.0, un attaccante MITM può modificare il ClientHello per forzare la negoziazione verso la versione più debole:

• POODLE (CVE-2014-3566): downgrade a SSL 3.0 + oracle su CBC padding
• DROWN (CVE-2016-0800): server che supportano SSLv2 possono compromettere chiavi TLS più recenti
• BEAST (CVE-2011-3389): attacco a TLS 1.0 in modalità CBC

Analisi del traffico TLS con Wireshark #

Wireshark può decifrare il traffico TLS se si ha la chiave privata del server o il file di sessione NSS:

# In Wireshark: Edit → Preferences → Protocols → TLS → Pre-Master-Secret log file
# Impostare il percorso del file SSLKEYLOGFILE

# Su Linux/macOS, impostare la variabile prima di avviare il browser
SSLKEYLOGFILE=~/ssl_keys.log firefox

Filtri Wireshark per TLS:

tls                             # Tutto il traffico TLS
tls.handshake.type == 1         # ClientHello
tls.handshake.type == 2         # ServerHello
tls.alert                       # Alert TLS (errori, chiusure)
tls.record.version == 0x0303    # TLS 1.2
tls.record.version == 0x0304    # TLS 1.3

Vulnerabilità TLS note #

Heartbleed (CVE-2014-0160) #

Buffer over-read in OpenSSL: permette di leggere memoria del server. Critica.

POODLE (CVE-2014-3566) #

Padding Oracle On Downgraded Legacy Encryption: downgrade a SSL 3.0 + attacco al padding CBC. Mitigation: disabilitare SSL 3.0.

BEAST (CVE-2011-3389) #

Browser Exploit Against SSL/TLS: attacco a TLS 1.0 CBC. Mitigato in browser moderni. Mitigation: usare TLS 1.2+.

DROWN (CVE-2016-0800) #

Decrypting RSA with Obsolete and Weakened eNcryption: server che accettano SSLv2 possono compromettere sessioni TLS 1.2. Mitigation: disabilitare SSLv2 ovunque.

ROBOT (CVE-2017-13099) #

Return Of Bleichenbacher’s Oracle Threat: attacco alla decifrazione RSA PKCS#1 v1.5 in alcuni stack TLS. Permette di decifrare sessioni TLS 1.2 senza forward secrecy.

Sweet32 (CVE-2016-2183) #

Birthday attack su cipher a 64 bit (3DES). Richiede ~785GB di traffico ma è pratico in sessioni lunghe. Mitigation: disabilitare 3DES.

Log4Shell + TLS #

Menzione separata: JNDI injection tramite headers TLS (User-Agent, SNI) era un vettore per Log4Shell — esempio di come l’analisi TLS intersechi vulnerabilità applicative.

Esempi pratici con TLS/SSL in laboratorio #

Setup di un server TLS con OpenSSL per test #

# Generare certificato self-signed per test
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

# Avviare server TLS minimale
openssl s_server -key key.pem -cert cert.pem -accept 4443 -www

# Testare la connessione
openssl s_client -connect localhost:4443

Scan massivo TLS con testssl.sh #

# Scan di una lista di host
while read host; do
  ./testssl.sh --quiet --csv "$host:443" >> results.csv
done < hosts.txt

sslyze: alternativa Python a testssl.sh #

pip install sslyze
sslyze --regular target.com
sslyze --certinfo --sslv2 --sslv3 --tlsv1 --tlsv1_1 target.com

Detection e difesa TLS/SSL #

• Monitorare le versioni TLS in uso: qualsiasi client che negozia TLS 1.0 o SSL è un problema
• Certificate Transparency: usare CT logs per rilevare certificati non autorizzati emessi per i propri domini
• HSTS Preloading: forzare HTTPS per evitare SSL stripping
• OCSP Stapling: ridurre la latenza e migliorare la privacy nella verifica dei certificati
• Certificate Pinning: per applicazioni mobile e API critiche

Hardening TLS #

Configurazione moderna (TLS 1.3 only o TLS 1.2+) #

Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 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_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
add_header Strict-Transport-Security "max-age=63072000" always;

Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

HSTS #

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Rinnovare i certificati prima della scadenza #

Usare Certbot con Let’s Encrypt per automatizzare il rinnovo dei certificati. Un certificato scaduto è una finding critica in qualsiasi pentest.

Errori comuni su TLS #

“HTTPS significa sicuro” HTTPS significa solo che il trasporto è cifrato. Non garantisce che l’applicazione sia sicura, che il certificato sia valido, o che la cipher suite non sia vulnerabile.

“TLS 1.2 è sicuro per default” Dipende dai cipher suite abilitati. TLS 1.2 con RC4, 3DES, o RSA key exchange è vulnerabile. TLS 1.2 con ECDHE + AES-GCM è sicuro.

“I certificati self-signed sono sicuri per uso interno” I certificati self-signed non forniscono autenticazione dell’identità — un attaccante può presentare il proprio certificato self-signed senza che i client se ne accorgano (se non c’è pinning o validazione). Per uso interno, usare una PKI interna con CA propria.

“Heartbleed è stato patchato ovunque” No. Sistemi embedded, apparati di rete, e applicazioni legacy con OpenSSL non aggiornato sono ancora vulnerabili a Heartbleed nel 2024.

FAQ su TLS/SSL #

Cos’è TLS e come si differenzia da SSL? TLS (Transport Layer Security) è il successore di SSL (Secure Sockets Layer). SSL è obsoleto e vulnerabile — SSL 2.0 e 3.0 non devono essere usati. TLS è il protocollo corrente. Nella pratica, “SSL” viene ancora usato informalmente per riferirsi a TLS.

Cos’è un cipher suite TLS? Un cipher suite è un insieme di algoritmi crittografici usati in una sessione TLS: key exchange, autenticazione, cifratura, e integrità. La scelta del cipher suite determina la sicurezza della connessione.

Cos’è la forward secrecy? La forward secrecy (o perfect forward secrecy, PFS) garantisce che la compromissione della chiave privata del server non permetta di decifrare le sessioni passate. Si ottiene usando ECDHE o DHE per il key exchange — ogni sessione usa chiavi effimere generate al momento.

Come si verifica se un server è vulnerabile a Heartbleed? Con Nmap: nmap -p 443 --script ssl-heartbleed target.com. Con testssl.sh: ./testssl.sh --heartbleed target.com. Un server vulnerabile restituisce dati di memoria in risposta a una heartbeat request malformata.

Cos’è HSTS e perché è importante? HTTP Strict Transport Security (HSTS) è un header HTTP che forza il browser a usare sempre HTTPS per quel dominio, impedendo il downgrade a HTTP. Senza HSTS, un attaccante MITM può fare SSL stripping, degradando la connessione a HTTP in chiaro.

Conclusione su TLS/SSL #

TLS è lo strato di sicurezza su cui si affida la maggior parte del traffico di rete moderno. Ma TLS configurato male è quasi peggio di nessun TLS: dà un falso senso di sicurezza mentre espone dati critici.

Versioni obsolete, cipher suite deboli, certificati scaduti, assenza di HSTS, vulnerabilità come Heartbleed: sono finding che compaiono regolarmente in qualsiasi web application assessment. Spesso in ambienti che si considerano sicuri perché “usano HTTPS”.

Testssl.sh e OpenSSL sono tutto ciò che serve per un’analisi TLS completa. Aggiungerla sistematicamente a ogni engagement fa la differenza.

Approfondisci i protocolli correlati:

• TCP: il trasporto sotto TLS
• HTTP e HTTPS: applicazione su TLS
• IPSec: cifratura alternativa a livello di rete
• SSH: cifratura applicativa
• Certificati X.509 e PKI
• Man in the Middle: SSL stripping
• Nmap: SSL/TLS scripts

Riferimento ufficiale: RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3

La configurazione TLS è una delle aree dove i problemi sono più frequenti e meno visibili. Se vuoi sapere dove sei esposto: hackita.it/servizi.

HackITA vive grazie a chi decide di contribuire: hackita.it/supporto