TLS/SSL: Come Testare Handshake, Cipher Suite, Certificati e Vulnerabilità in un Pentest #

TLS è il protocollo che cifra la maggior parte del traffico di rete moderno. Capire 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 è oggi lo standard di riferimento, ed è già in fase di evoluzione verso la resistenza quantistica (vedi più avanti).

Se non sai bene la differenza tra cifratura, hashing e codifica prima di andare avanti, questa guida pratica alla crittografia con esempi reali copre le basi in modo semplice — utile come ripasso prima di entrare nei dettagli tecnici di TLS.

Checklist rapida per un TLS assessment #

• Versioni TLS/SSL supportate (SSLv2/3, TLS 1.0/1.1 attivi = problema)
• Cipher suite deboli (RC4, 3DES, NULL, EXPORT, senza forward secrecy)
• Certificato: validità, CN/SAN corretto, catena di trust, revoca (OCSP/CRL)
• HSTS presente e con max-age adeguato
• Vulnerabilità note: Heartbleed, POODLE, BEAST, DROWN, ROBOT, Sweet32, FREAK, Logjam, CCS Injection, Renegotiation, CRIME/BREACH
• Downgrade e SSL stripping possibili
• STARTTLS injection sui servizi SMTP/IMAP/POP3/FTP con STARTTLS opzionale
• Se TLS 1.3 con 0-RTT: rischio replay su endpoint non idempotenti
• Se mTLS: validazione reale del certificato client, non solo a livello di edge/proxy
• Gruppo di key exchange negoziato (classico vs ibrido post-quantum)
• ECH abilitato lato client, se rilevante per il contesto dell’engagement

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 — vedi sotto)

Il rischio concreto dello 0-RTT: replay attack. I dati inviati come “early data” in una sessione 0-RTT non hanno la stessa garanzia di freshness del resto della sessione: un attaccante che intercetta il pacchetto iniziale può ritrasmetterlo (replay) e il server, se non implementa protezioni aggiuntive, lo elaborerà di nuovo come se fosse una richiesta legittima. In un pentest, questo è un finding concreto su qualsiasi endpoint che accetta 0-RTT per richieste non idempotenti (es. un endpoint di pagamento, di creazione ordine, o qualunque azione con effetti collaterali). Verifica se il server implementa un meccanismo anti-replay (es. cache delle richieste 0-RTT già viste) o se accetta 0-RTT solo per richieste sicuramente idempotenti (GET senza side effect).

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)

Encrypted Client Hello (ECH): il nuovo livello di privacy in TLS 1.3 #

Fino a poco tempo fa, anche con TLS 1.3, il campo SNI (Server Name Indication) nel ClientHello viaggiava in chiaro: chiunque osservasse il traffico (ISP, firewall aziendale, proxy MITM) poteva vedere a quale dominio ti stavi connettendo, anche se il contenuto della sessione restava cifrato.

ECH (Encrypted Client Hello), standardizzato con RFC 9849 (marzo 2026), non cifra il ClientHello in senso assoluto: lo divide in due. Il client invia un ClientHelloOuter in chiaro, con un hostname placeholder (public_name, spesso quello del CDN, es. un dominio Cloudflare generico), e dentro ci incapsula il vero ClientHelloInner — quello con l’SNI reale — cifrato via HPKE con una chiave pubblica del server pubblicata su DNS (record HTTPS/SVCB). È già supportato di default da Cloudflare, Chrome e Firefox, e da inizio 2026 anche NGINX lo supporta nativamente (dalla versione 1.29.4).

Perché conta in un pentest:

• Un proxy di ispezione posizionato in mezzo vede comunque un SNI nel ClientHelloOuter — solo che è un placeholder, non l’hostname reale. Un controllo di content filtering basato sul SNI in chiaro perde quindi la sua funzione per quel dominio specifico, ma solo se ECH è effettivamente negoziato: se il proxy blocca l’estensione ECH stessa o impedisce la risoluzione DNS del relativo ECHConfig, il client fa fallback su un ClientHello normale.
• Se stai testando un ambiente enterprise con controlli di rete basati sul SNI in chiaro, verifica se i client hanno ECH abilitato e se la rete lascia passare le query DNS che risolvono l’ECHConfig: solo in quel caso il controllo è bypassabile.
• Verifica supporto ECH su un dominio:

# Controllo DNS del record HTTPS/SVCB con parametro ECH
dig +short TYPE65 target.com

# Test diretto con OpenSSL 3.4+
openssl s_client -connect target.com:443 -ech

ECH non sostituisce DNS-over-HTTPS: senza DoH, la query DNS che risolve il dominio resta comunque osservabile. Le due tecnologie vanno insieme per una privacy completa del canale.

TLS post-quantum: hybrid key exchange già in produzione #

Questo è un cambiamento reale nella superficie che un pentester deve conoscere, non un argomento teorico da paper accademico: nel 2026, tra il 30% e il 50% degli handshake TLS su Chrome, Firefox e le principali CDN (Cloudflare, Fastly, AWS CloudFront) usa già uno scambio chiavi ibrido post-quantistico.

Il gruppo standard è X25519MLKEM768: combina il classico ECDH su curva X25519 con ML-KEM-768 (il KEM lattice-based standardizzato da NIST come FIPS 203, ex Kyber). Il client genera entrambe le chiavi effimere e le invia nello stesso key_share extension del ClientHello; il segreto condiviso finale è la combinazione HKDF dei due segreti. Se anche uno solo dei due schemi venisse rotto in futuro (sia da un computer quantistico su X25519, sia da un breakthrough di crittanalisi su ML-KEM), la sessione resta protetta dall’altro.

Timeline di adozione:

Perché serve saperlo in un pentest:

• ClientHello più grande. Una key share ML-KEM pesa circa 1.2 KB, il che spinge il ClientHello oltre un singolo segmento TCP. Middlebox vecchi o mal configurati che non gestiscono bene ClientHello frammentati possono rompere la connessione — un problema di compatibilità da tenere presente in ambienti con proxy/IDS datati.
• Fingerprinting TLS (JA3/JA4). Un client che dichiara Chrome/Firefox ma non offre i gruppi ibridi PQ nel ClientHello ha una firma TLS inconsistente con quella del browser dichiarato — è un segnale che alcuni sistemi anti-bot e anti-scraping usano oggi per individuare traffico automatizzato o tool che spoofano lo User-Agent senza aggiornare lo stack TLS sottostante.
• Certificati post-quantum sono un’altra cosa. Attenzione a non confondere i due livelli: lo scambio di chiavi ibrido protegge la sessione da attacchi “harvest now, decrypt later”, ma la firma del certificato del server nella maggior parte dei casi resta classica (RSA/ECDSA). Le firme post-quantum (ML-DSA, FIPS 204) sono in fase di adozione molto più lenta.

Verifica quale gruppo è stato negoziato:

# OpenSSL 3.5+
openssl s_client -groups X25519MLKEM768:X25519 -connect target.com:443
# Cerca nell'output: "Negotiated TLS1.3 group: X25519MLKEM768"

# testssl.sh (versioni recenti riportano il gruppo PQ negoziato)
./testssl.sh --protocols target.com:443

Un client senza supporto PQ negozia automaticamente su un gruppo classico (fallback trasparente) — quindi non aspettarti errori, solo un gruppo diverso in output.

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 (per la negoziazione delle chiavi SRTP) e da alcuni VPN. QUIC non passa da DTLS: integra TLS 1.3 direttamente come proprio livello di cifratura (RFC 9001), riusando l’handshake ma non il record layer classico.

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
• Client TLS obsoleti: stack senza supporto ai gruppi PQ ibridi, spesso indicatori di librerie o tool non aggiornati in ambienti enterprise

Per il protocollo TCP su cui TLS opera, vedi TCP. Per una tecnologia VPN alternativa a livello di rete, che non usa l’handshake 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

# Flag dedicati per singole vulnerabilità
./testssl.sh -F target.com:443   # FREAK
./testssl.sh -J target.com:443   # Logjam
./testssl.sh -I target.com:443   # CCS Injection
./testssl.sh -R target.com:443   # Renegotiation
./testssl.sh -C target.com:443   # CRIME
./testssl.sh -B target.com:443   # BREACH

Output: versioni supportate, cipher suite per versione, certificato, gruppo di key exchange negoziato (incluso PQ), 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

JARM: fingerprinting attivo del server TLS #

JARM genera un hash basato su come un server risponde a diverse combinazioni anomale di ClientHello (ordine cipher suite, estensioni, versioni). Utile in fase di recon per identificare server con la stessa configurazione TLS (es. la stessa infrastruttura C2, lo stesso CDN, o server dietro load balancer diversi ma con stack identico) senza basarsi solo su banner o certificato.

pip install jarm
python3 jarm.py target.com -p 443

Due host con lo stesso hash JARM condividono probabilmente la stessa implementazione/configurazione TLS, anche se hanno IP e certificati completamente diversi — utile per mappare infrastrutture correlate durante la ricognizione.

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

# Verificare se il certificato è stato revocato (OCSP)
openssl s_client -connect target.com:443 -status 2>/dev/null | grep -A5 "OCSP Response"

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

STARTTLS Injection #

Diverso da SSL stripping: qui il problema non è degradare HTTPS a HTTP, ma iniettare comandi in chiaro prima che il canale STARTTLS venga effettivamente attivato, su protocolli come SMTP, IMAP, POP3 o FTP (CVE-2011-0411 e varianti simili emerse negli anni successivi su implementazioni diverse). Se il server non tronca correttamente il buffer di lettura al momento dello switch a TLS, un attaccante MITM può inserire comandi prima dell’handshake che vengono eseguiti come se arrivassero dopo, con la vittima ignara.

# testssl.sh supporta il test diretto su servizi STARTTLS
./testssl.sh --starttls smtp target.com:587
./testssl.sh --starttls imap target.com:143
./testssl.sh --starttls ftp target.com:21

# Test manuale STARTTLS su SMTP
openssl s_client -starttls smtp -crlf -connect target.com:587

Rilevante ogni volta che il target espone servizi SMTPS/IMAPS/POP3S/FTPS non nativamente cifrati (porta dedicata TLS) ma con STARTTLS opzionale sulla porta in chiaro.

mTLS: bypass dell’autenticazione client #

Con mutual TLS (mTLS), non solo il client verifica il certificato del server: anche il server richiede e valida un certificato del client. È comune su API interne, microservizi e ambienti zero-trust. Punti da testare in un pentest:

• Validazione debole del certificato client: il server accetta certificati self-signed, scaduti, o con CN/SAN non pertinente? Prova con un certificato generato al volo:

openssl req -x509 -newkey rsa:2048 -keyout fake-key.pem -out fake-cert.pem -days 1 -nodes
openssl s_client -connect target.com:443 -cert fake-cert.pem -key fake-key.pem

• mTLS solo a livello di reverse proxy: se l’autenticazione client-cert avviene solo sul proxy edge (es. un load balancer) e il backend non verifica nulla lato applicativo, un accesso diretto al backend (bypassando il proxy) può saltare completamente il controllo.
• Fallback silenzioso su TLS senza client cert: verifica se il server, in assenza di certificato client, si limita a rifiutare la richiesta applicativa invece di chiudere la connessione TLS — un comportamento che a volte espone endpoint pensati per essere protetti solo da mTLS.

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

Nota: se il target usa ECH, il campo SNI non sarà leggibile in chiaro nemmeno con la chiave privata del server applicativo — serve la chiave ECH specifica del punto che termina l’ECH (spesso un CDN come Cloudflare, non il server origin).

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.

FREAK (CVE-2015-0204) #

Factoring RSA Export Keys: forza il downgrade a cipher suite RSA “export” a 512 bit (retaggio delle vecchie restrizioni USA sull’export di crittografia), rendendo la chiave fattorizzabile in tempi pratici. Richiede un MITM per forzare il downgrade. Mitigation: disabilitare tutte le cipher suite _EXPORT_.

Logjam (CVE-2015-4000) #

Simile a FREAK ma sul lato Diffie-Hellman: forza un downgrade a gruppi DHE export a 512 bit. Un attaccante con risorse sufficienti può precalcolare i log discreti per i gruppi DH più comuni e rompere lo scambio chiavi in tempo reale. Mitigation: disabilitare le cipher suite DHE export, usare gruppi DH da almeno 2048 bit o passare a ECDHE.

CCS Injection (CVE-2014-0224) #

Vulnerabilità nella gestione del messaggio ChangeCipherSpec in alcune versioni di OpenSSL: un attaccante MITM può forzare l’uso di chiavi deboli o predicibili iniettando il messaggio CCS nel momento sbagliato dell’handshake. Mitigation: aggiornare OpenSSL.

Renegotiation Attack (CVE-2009-3555) #

La rinegoziazione TLS non autenticata permette a un attaccante di iniettare dati in chiaro all’inizio di una sessione che poi la vittima “completa” rinegoziando — nei casi peggiori si traduce in richieste HTTP arbitrarie eseguite con le credenziali della vittima. Mitigation: richiedere Secure Renegotiation (RFC 5746), disabilitare la rinegoziazione client-initiated se non necessaria.

CRIME e BREACH #

CRIME (CVE-2012-4929) sfrutta la compressione a livello TLS per dedurre byte per byte i dati cifrati osservando le variazioni di dimensione del traffico compresso. BREACH è l’equivalente a livello di compressione HTTP (gzip), più difficile da mitigare perché la compressione HTTP è spesso necessaria per le performance. Mitigation: disabilitare la compressione TLS (CRIME); per BREACH, evitare di riflettere segreti (token CSRF, ecc.) nello stesso body compresso insieme a input controllato dall’utente.

CVE-2025-66199 — DoS su compressione certificati TLS 1.3 #

Vulnerabilità più recente (patch OpenSSL gennaio 2026, severità bassa): una connessione TLS 1.3 che usa la compressione dei certificati (CompressedCertificate) può essere forzata ad allocare un buffer enorme prima di validare la dimensione configurata, causando denial of service. Riguarda OpenSSL 3.3, 3.4, 3.5 e 3.6 non aggiornati. Un promemoria pratico: anche funzionalità di ottimizzazione recenti di TLS 1.3 possono introdurre superfici di attacco nuove.

Log4Shell + TLS #

Non è una vulnerabilità di TLS, ma un punto di intersezione da conoscere: durante Log4Shell (CVE-2021-44228), il payload JNDI veniva iniettato in qualunque campo che finiva loggato da un’applicazione Log4j vulnerabile — non solo body e header HTTP classici (User-Agent, X-Forwarded-For), ma in alcuni setup anche il valore del SNI, quando un reverse proxy o load balancer lo registrava nei propri log applicativi. Non è TLS in sé a essere vulnerabile: è l’abitudine di loggare in chiaro qualsiasi campo passato dal client, incluso uno che normalmente si considera “solo di trasporto”.

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

sslscan: check rapido da riga di comando #

sslscan target.com:443

Output più compatto di testssl.sh — utile per una prima passata veloce prima di un’analisi approfondita.

curl: verifica rapida di HSTS e versioni TLS #

# Controllare se HSTS è presente
curl -sI https://target.com | grep -i strict-transport-security

# Forzare una versione TLS specifica
curl --tlsv1.2 --tls-max 1.2 -Iv https://target.com
curl --tlsv1.3 -Iv https://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
• Pianificare la migrazione post-quantum: partire dall’inventario degli endpoint TLS, verificare quali librerie supportano già i gruppi ibridi (OpenSSL 3.5+, Go standard library senza configurazione custom), e non confondere “supporto allo scambio chiavi ibrido” con “certificato post-quantum” — sono due livelli distinti della migrazione

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 è quasi sempre una finding degna di nota — la severità reale (Low/Medium più spesso di High) dipende dal contesto: quanto è esposto il servizio, se il certificato scaduto è combinato con altre debolezze, e da quanto tempo è scaduto.

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.

“Il post-quantum in TLS è ancora teoria” No, non più: nel 2026 tra il 30% e il 50% degli handshake TLS 1.3 su browser e CDN principali usa già uno scambio chiavi ibrido post-quantistico di default.

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.

Cos’è ECH e cambia qualcosa per un pentest? Encrypted Client Hello (RFC 9849) cifra l’intero ClientHello, incluso il campo SNI che prima era visibile in chiaro anche su TLS 1.3. In un ambiente con ECH abilitato, i controlli di rete basati sull’ispezione del SNI in chiaro (content filtering, alcune regole IDS/DLP) smettono di funzionare — un punto da verificare in ogni assessment su reti enterprise.

Il TLS post-quantum rende obsoleti gli attacchi TLS classici? No. Lo scambio di chiavi ibrido post-quantistico protegge solo contro un futuro attacco “harvest now, decrypt later” basato su computer quantistici. Non ha nessun effetto su cipher suite deboli, certificati scaduti, SSL stripping o downgrade attack — quelle vulnerabilità restano identiche e vanno testate allo stesso modo.

TLS 1.2 è ancora sicuro da usare nel 2026? Sì, ma solo con la configurazione giusta: cipher suite ECDHE/DHE per la forward secrecy, AES-GCM o ChaCha20-Poly1305, niente RC4/3DES/RSA key exchange. TLS 1.2 mal configurato è vulnerabile quanto una versione obsoleta; TLS 1.2 ben configurato resta accettabile, anche se TLS 1.3 è preferibile dove possibile.

Qual è il modo più veloce per controllare la configurazione TLS di un server? sslscan target.com:443 per un check rapido, curl -sI https://target.com | grep -i strict-transport-security per verificare HSTS in un secondo. Per un’analisi completa serve comunque testssl.sh.

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”. Nel frattempo il protocollo continua a evolvere — ECH e lo scambio di chiavi post-quantistico sono già realtà di produzione, non roadmap futura, e vale la pena includerli nella checklist di un assessment aggiornato.

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

Riferimenti ufficiali: RFC 8446 — TLS 1.3, RFC 9849 — Encrypted Client Hello