In un SOC la crittografia non è qualcosa che configuri, ma qualcosa che osservi: la incontri già in funzione dentro le sessioni TLS, i log del proxy e le catture di pacchetti. Il compito dell’analista non è scegliere un algoritmo, ma riconoscerlo — capire se un flusso è cifrato o solo firmato, quali metadati restano leggibili senza decryption e quando un artefatto crittografico (un certificato anomalo, un hash che non torna) è un indicatore di compromissione.
Encryption simmetrica vs asimmetrica
Le due famiglie hanno firme osservabili diverse sul filo. La simmetrica (una chiave condivisa) trasporta il bulk del traffico applicativo: è ciò che vedi come payload cifrato illeggibile dopo l’handshake. L’asimmetrica (coppia public/private) compare solo all’avvio della sessione, nella fase di setup delle chiavi e nell’autenticazione via certificato. Per il triage conta sapere dove guardare ciascuna.
| Cosa vede il SOC | Simmetrica | Asimmetrica |
|---|---|---|
| Dove nel flusso | Payload dopo l’handshake | Fase di setup e certificati |
| Algoritmi nel cipher suite | AES-GCM/CBC, ChaCha20 | RSA, ECDSA, (EC)DHE |
| Cosa resta visibile | Solo volume/timing dei byte | Certificato, parametri di scambio |
| Segnale d’allarme | Entropia alta su porte inattese | Cert self-signed, issuer sconosciuto |
L’asimmetrica è lenta e serve solo a negoziare una chiave di sessione simmetrica; da lì tutto il traffico passa alla simmetrica, veloce. Questo spiega perché, aprendo un pcap, i primi pacchetti mostrano certificati e scambio chiavi, e subito dopo diventa tutto opaco.
Hashing e HMAC
L’hashing è one-way: SHA-256 produce un digest a 256 bit non invertibile, senza chiave. In un SOC lo usi per matchare gli IOC: confronti l’hash di un file estratto dal traffico o dall’endpoint contro le threat intel feed (VirusTotal, MISP). MD5 e SHA-1 restano diffusi negli IOC storici ma sono deboli per collisioni.
Un hash “nudo” prova l’integrità del bit, non l’origine: chi altera un pacchetto può ricalcolarlo. HMAC (Hash-based Message Authentication Code) lega l’hash a una chiave segreta condivisa, aggiungendo l’autenticazione dell’origine. TLS e IPsec lo usano (o l’equivalente AEAD in AES-GCM) per proteggere ogni record: è ciò che impedisce a un man-in-the-middle di iniettare pacchetti nella sessione senza rompere la MAC.
Handshake TLS e cosa resta visibile
Nel TLS handshake il client e il server negoziano la cipher suite, il server presenta il certificato X.509, e le parti derivano via ECDHE una chiave di sessione (garantendo la Perfect Forward Secrecy, PFS). Per il SOC il punto cruciale è la superficie di visibilità:
- Fino a TLS 1.2 il certificato del server viaggia in chiaro: issuer, CN/SAN, validità sono ispezionabili.
- Il campo SNI (Server Name Indication) del ClientHello rivela l’hostname richiesto — utile per il DNS/URL filtering — a meno che non sia attivo Encrypted Client Hello.
- La PFS con chiavi effimere significa che, anche recuperando la private key del server, non puoi decifrare a posteriori le sessioni catturate.
Ispezione del traffico cifrato
Poiché il payload è opaco, il SOC ha due strade. La prima è il decryption proxy (SSL/TLS interception): un middlebox termina il TLS, ispeziona in chiaro e ri-cifra verso il server, presentando ai client un certificato firmato da una CA aziendale nel loro trust store. È potente ma costoso, solleva problemi di privacy e rompe il pinning.
La seconda è l’analisi cifrata senza decryption: qui entra JA3/JA3S, un fingerprint calcolato dai parametri del ClientHello/ServerHello (versioni, cipher suite, estensioni). Malware e tool offensivi generano JA3 ricorrenti, quindi puoi identificare famiglie di C2 anche dentro TLS opaco. A questo si aggiungono metadati di flusso: SNI, certificato, byte/timing, JARM. È l’approccio della encrypted traffic analysis.
Trappole tipiche d’esame
- “Il traffico C2 è dentro TLS e non hai un proxy di decryption: come lo identifichi?” → fingerprinting JA3/JA3S e analisi dei metadati (SNI, certificato, pattern di flusso), non decifrando il payload.
- “Cosa resta ispezionabile in una sessione TLS senza decryption?” → SNI, certificato del server, JA3, volume/timing; il payload applicativo resta opaco.
- “È attiva la PFS (ECDHE): puoi decifrare a posteriori un pcap avendo la private key del server?” → No; le chiavi effimere rendono impossibile la decryption retrospettiva.
- “L’handshake presenta un certificato self-signed con issuer sconosciuto su una porta alta” → indicatore di C2/tunneling: la validazione X.509 fallirebbe la chain of trust, segnale da escalare.
- “L’integrità di un pacchetto va provata insieme all’origine autenticata” → HMAC/AEAD, non un hash puro (ricalcolabile da un attaccante in-path).