Che cos’è il traffico crittografato?

La stragrande maggioranza del traffico Internet è crittografata, principalmente utilizzando TLS per garantire la riservatezza, l’integrità e l’autenticità dei dati. Il Transport Layer Security (TLS) è un protocollo di rete che avvolge altri protocolli in uno strato di crittografia ed è la differenza tra HTTP e HTTPS per il traffico web. La crittografia protegge contro l’intercettazione, ma non garantisce che il traffico crittografato sia sicuro.

Sebbene il TLS sia meglio conosciuto per la sua crittografia dei dati, offre anche protezione per l’integrità e l’autenticità dei dati. Per impostazione predefinita, HTTPS autentica l’identità del server utilizzando un certificato digitale, e il TLS mutuo (mTLS) fa lo stesso anche per il client.

Punti salienti

• Il traffico crittografato è comunicazione di rete protetta in transito, più comunemente con TLS.
• La crittografia migliora la riservatezza e l’integrità, ed è ora il default per la maggior parte del traffico web e delle app.
• I payload crittografati riducono ciò che molti strumenti di sicurezza di rete possono osservare e far rispettare direttamente.
• Le organizzazioni gestiscono il traffico crittografato utilizzando un mix di politiche, ispezione basata su decrittazione selettiva e metodi di visibilità non decrittografati.
• I protocolli moderni e le funzionalità di privacy, inclusi i comportamenti di TLS 1.3, QUIC, HTTP/3 e ECH, possono cambiare quali metadati rimangono osservabili.
• I team di solito devono bilanciare la visibilità della sicurezza con l’affidabilità delle applicazioni, la privacy degli utenti e i requisiti di minimizzazione dei dati.

Cosa significa “crittografato” nel traffico di rete?

Il traffico crittografato si riferisce alla crittografia dei dati in transito, spesso utilizzando TLS (un sostituto per l’SSL non sicuro). I dati possono anche essere crittografati a riposo utilizzando AES e algoritmi simili. La crittografia dei dati in transito converte il traffico di rete in testo cifrato illeggibile prima che il mittente lo trasmetta attraverso la rete. Il destinatario ha la chiave di decrittazione e può usarla per ripristinare i dati originali.

Quali sono esempi comuni di traffico crittografato?

La maggior parte del traffico Internet è ora crittografata poiché la crittografia aiuta a garantire l’autenticità e l’integrità dei dati trasmessi, oltre a proteggerli contro l’intercettazione. Ad esempio, la maggior parte del traffico web moderno – inclusi la navigazione web, il traffico delle applicazioni SaaS, le chiamate API e il traffico delle app mobili – utilizza il protocollo HTTPS crittografato, che avvolge HTTP in TLS.

Anche altri protocolli di rete sono crittografati, sia per design che attraverso l’uso di TLS. Esempi includono:

• Traffico VPN (da sito a sito e per utenti remoti)
• Trasporto e recupero di email sicure (SMTPS, IMAPS, POP3S)
• Protocolli di amministrazione e trasferimento file (SSH, SFTP)
• Flussi multimediali moderni di voce e video (SRTP), oltre al traffico delle app di conferenza

Perché il traffico crittografato è diventato la norma

La maggior parte dei protocolli di rete che compongono l’internet moderno (HTTP, DNS, ecc.) non sono sicuri per impostazione predefinita, mancando di crittografia dei dati, autenticazione e protezione dell’integrità. Oggi, l’uso di protocolli crittografati è diventato la norma per diversi motivi, tra cui:

• Privacy dei dati
• Sicurezza migliorata
• Conformità normativa:
• Impostazioni predefinite dei browser web e delle piattaforme

Perché il traffico crittografato è importante per la sicurezza e le operazioni

La crittografia del traffico utilizzando TLS ha diversi vantaggi, proteggendo la riservatezza, l’integrità e l’autenticità dei dati. Questo è importante perché, senza di essa, il traffico di rete potrebbe essere vulnerabile a intercettazioni e modifiche durante il percorso verso la sua destinazione. Allo stesso tempo, la crittografia del traffico crea anche sfide di sicurezza poiché, come gli aggressori, gli strumenti di sicurezza non possono leggere i contenuti del traffico crittografato per impostazione predefinita. Questo è problematico perché malware, informazioni personali identificabili (PII) e exploit di vulnerabilità possono essere nascosti all’interno del traffico crittografato.

Decrittografare il traffico di rete richiede accesso ai punti finali o la rottura della connessione TLS e l’esecuzione di una decrittografia TLS computazionalmente costosa all’interno degli strumenti di sicurezza di rete. Di conseguenza, gli strumenti di sicurezza utilizzano spesso metadati, segnali di prestazione e telemetria dei punti finali per identificare potenziali minacce.

Cosa possono ancora vedere i team di sicurezza quando il traffico è crittografato?

Mentre TLS crittografa il contenuto di un pacchetto di rete, alcune informazioni devono rimanere decrittografate per consentire al pacchetto di raggiungere la sua destinazione. Alcuni dei metadati che i team di sicurezza possono ancora vedere nel traffico crittografato includono:

• Indirizzi IP di origine e di destinazione
• Porte di origine e di destinazione.
• Caratteristiche di temporizzazione, volume e flusso.
• Alcuni dettagli di handshake e certificato (che cambiano con ECH e sforzi di privacy)

Tuttavia, l’utilità di queste informazioni dipende anche da come il traffico è crittografato. Se viene utilizzato un VPN IPsec invece di TLS per la crittografia, gli indirizzi IP e le porte punteranno ai punti finali della VPN, non alle destinazioni finali del traffico di rete.

Come le organizzazioni gestiscono il traffico crittografato negli ambienti aziendali

Le organizzazioni possono adottare due approcci diversi per gestire i rischi di sicurezza del traffico crittografato:

1. Decrittografare il traffico e ispezionare i contenuti
2. Esaminare i metadati non crittografati per inferire il rischio senza decrittografia

Spesso, le organizzazioni utilizzano una combinazione delle due tecniche. Ad esempio, possono impostare come predefinito l’esame dei metadati e eseguire la decrittografia solo per il traffico identificato come potenzialmente rischioso.

Approccio 1: Ispezione basata sulla decrittografia

Il primo approccio potenziale è ispezionare il traffico crittografato, noto anche come ispezione TLS o SSL. In questo modello, un dispositivo di sicurezza decrittografa il traffico in un punto di ispezione, lo valuta e poi lo ri-crittografa per la consegna. Questo consente all’organizzazione di applicare politiche, rilevare minacce, scansionare malware e implementare controlli sui contenuti che richiedono visibilità nel payload.

Tuttavia, questo approccio introduce anche rischi poiché richiede di interrompere la connessione TLS crittografata, spesso creando due connessioni crittografate separate, una dal client all’apparecchiatura di sicurezza e l’altra dall’apparecchiatura al server. La decrittazione introduce rischi per la privacy, può danneggiare le prestazioni e aggiunge complessità che potrebbe interrompere le applicazioni.

Come funziona l’ispezione basata sulla decrittazione?

L’ispezione basata sulla decrittazione funziona interrompendo la sessione TLS crittografata in due sessioni separate con un punto di decrittazione nel mezzo. Questo include i seguenti passaggi:

1. Il client avvia una sessione TLS.
2. Il punto di ispezione intercetta e termina la sessione.
3. Il punto di ispezione stabilisce una sessione TLS separata verso la destinazione.
4. Il contenuto viene decrittato e ispezionato secondo la politica.
5. Il traffico viene nuovamente crittografato e inoltrato.

Quale ruolo svolgono i certificati e i depositi di fiducia?

Affinché il punto di ispezione possa creare una sessione con il client, il client deve accettare che il suo certificato digitale sia un certificato valido per il sito di destinazione. Questo è spesso implementato come un certificato digitale wildcard che si applica a qualsiasi sito che il client potrebbe visitare.

Questo approccio richiede una significativa fiducia nell’impresa e nella sua sicurezza poiché il client non può più convalidare il vero certificato digitale fornito dal sito di destinazione. Di conseguenza, questo certificato digitale è una fonte comune di configurazioni errate, rischi per la sicurezza e interruzioni.

Cosa viene ispezionato dopo la decrittazione?

Dopo che il traffico è stato decrittato al punto di ispezione, l’apparecchiatura di sicurezza ha accesso completo al payload del pacchetto. Questo le consente di implementare varie funzioni di sicurezza, come:

• Filtraggio URL
• Scansione malware
• Controlli del tipo di file
• Prevenzione della perdita di dati
• Identificazione degli indicatori di minaccia nel contenuto

Approccio 2: Visibilità non decrittata

La decrittazione non è sempre un’opzione (o la migliore opzione). Un’alternativa è che gli strumenti di sicurezza inferiscano il rischio associato a una connessione utilizzando metadati, comportamento del flusso, telemetria degli endpoint e altri segnali senza decrittare il contenuto del payload. I segnali utilizzati per questa analisi includono:

• Analisi basata sul flusso
• Anomalie comportamentali
• Intelligence su IP e domini noti come dannosi
• Anomalie di certificato e handshake (dove visibili)
• Fingerprinting TLS e caratteristiche del client hello (dove visibili)
• Metadati SNI e ALPN quando non protetti da ECH
• Reputazione del certificato e anomalie (schemi dell’emittente, finestre di validità, catene auto-firmate sospette)
• Classificazione della destinazione più baselines storiche per rapporti di byte, schemi di picco e durate delle sessioni

Questo approccio ha alcuni vantaggi poiché elimina il sovraccarico e i rischi per la privacy associati alla decrittazione del traffico. Tuttavia, potrebbero mancare minacce visibili solo all’interno del payload del traffico di rete. Le organizzazioni possono anche utilizzare analisi del traffico crittografato basata su AI per migliorare l’efficacia di questa tecnica.

Cosa si rompe nel mondo reale quando si gestisce il traffico crittografato?

Decrittare il traffico crittografato per l’analisi può introdurre potenziali problemi per l’azienda. Per evitare interruzioni delle applicazioni, le organizzazioni dovrebbero implementare determinate politiche e controlli tecnici.

Certificato Pinning e Validazione Rigorosa del Certificato

La decrittazione del traffico aziendale richiede tipicamente la sostituzione del certificato digitale del server con un certificato di ispezione aziendale. Questo può essere problematico se un’applicazione implementa il certificato pinning o la validazione rigorosa del certificato, accettando solo un particolare certificato digitale per un sito web target.

Se questo è il caso, le applicazioni potrebbero non funzionare, sperimentare loop di autenticazione o non riuscire ad aggiornarsi. Le soluzioni possibili includono il bypass dell’ispezione per queste app, l’uso di controlli di sicurezza degli endpoint per ispezionare il traffico prima/dopo la crittografia, o la revisione delle linee guida del fornitore per le soluzioni.

Mutual TLS (mTLS) e Autenticazione del Certificato del Client

Il Mutual TLS (mTLS) autentica sia il client che il server utilizzando certificati digitali. Questo può causare il fallimento dell’intercettazione se il punto di ispezione non riesce a passare correttamente, validare o ri-originate l’autenticazione del certificato del client. 

I risultati possibili includono fallimenti delle API, richieste di autenticazione ripetute e improvvisi errori di “non autorizzato” dopo aver abilitato l’ispezione. Per mitigare questo, le organizzazioni possono bypassare l’ispezione per destinazioni mTLS specifiche, utilizzare controlli consapevoli degli endpoint o configurare un supporto esplicito per il passaggio del certificato del client, dove disponibile.

Protocolli Non Supportati, Cifrature e Casi Limite

Gli strumenti di ispezione potrebbero non supportare ogni protocollo o schema di negoziazione utilizzato da un’applicazione e/o server. Se questo è il caso, il punto di ispezione potrebbe non riuscire a negoziare una o entrambe le connessioni crittografate che mantiene con il client e il server.

I sintomi di questo problema includono fallimenti di connessione, timeout intermittenti e caricamenti parziali delle pagine. Le potenziali mitigazioni includono l’aggiornamento del punto di ispezione per includere protocolli mancanti o la ridefinizione delle politiche di ispezione per escludere quell’applicazione.

HTTP/3, QUIC, Comportamenti di TLS 1.3 e ECH

I protocolli moderni, come HTTP/3, QUIC e ECH, cambiano il modo in cui funziona l’intercettazione o i metadati non crittografati utilizzati per analizzare il traffico crittografato. Ad esempio, l’Encrypted Client Hello (ECH) crittografa una maggiore parte del handshake TLS, riducendo i dati non crittografati disponibili.

Di conseguenza, l’organizzazione potrebbe aver bisogno di strumenti aggiornati o approcci diversi per i flussi di rete che utilizzano questi protocolli. Alcune organizzazioni bloccano temporaneamente o degradano QUIC/HTTP/3 (forzando HTTP/2 su TLS) per preservare l’ispezione e l’applicazione coerente delle politiche, quindi riabilitano man mano che gli strumenti e le politiche maturano.

Confini di Privacy e Categorie Regolate

In alcuni casi, l’ispezione non dovrebbe essere eseguita anche se tecnicamente possibile. Ad esempio, molte organizzazioni eviteranno di decrittografare il traffico verso portali sanitari, banche, email personali e sistemi di self-service per i dipendenti per mantenere la conformità alle leggi sulla privacy dei dati. Per evitare di accedere a dati personali sensibili, i programmi di decrittografia del traffico dovrebbero essere sotto rigorosa governance, auditabili e decrittografare il minor numero possibile di dati sensibili e privati.

Come può degradare la performance con più salti di ispezione?

La decrittografia è costosa in termini computazionali e può introdurre latenza nelle connessioni di rete. Se più dispositivi di sicurezza o proxy decrittografano e ri-encryptano indipendentemente i dati, questo può aumentare la latenza di rete e i potenziali guasti, causando caricamenti lenti delle pagine, timeout e performance incoerenti.

Cosa significa ispezione “Single-Pass” o “Single-Scan”?

L’ispezione single-pass o single-scan esegue un solo giro di decrittografia/ri-encryptazione del traffico per l’ispezione della sicurezza. Più funzioni di sicurezza possono accedere ai dati decrittografati, offrendo lo stesso livello di sicurezza riducendo il numero di passaggi crittografici ridondanti e la latenza di rete associata.

Migliori Pratiche per Gestire il Traffico Crittografato Senza Compromettere il Business

L’ispezione del traffico crittografato può essere necessaria per la sicurezza, ma può anche danneggiare il business se implementata in modo errato. Alcune migliori pratiche includono:

• Iniziare con obiettivi chiari e casi d’uso.
• Definire esplicitamente le categorie di decrittografia rispetto a quelle di bypass.
• Eseguire un progetto pilota con gruppi non critici e set di app noti.
• Monitorare le performance, i tassi di errore e l’impatto sugli utenti.
• Costruire un processo di eccezione per app bloccate e casi di rottura ad alto rischio.
• Minimizzare la registrazione e la conservazione dei contenuti decrittografati. 
• Utilizzando i principi di raccolta minima.

Come dovrebbero le squadre decidere cosa decrittografare rispetto a cosa bypassare?

La decrittografia del traffico non è sempre necessaria e le organizzazioni devono decidere se il traffico richiede decrittografia. Alcuni fattori da considerare includono:

• Criticità aziendale
• Sensibilità dei dati e rischio per la privacy
• Esposizione alle minacce e probabilità di abuso
• Comportamenti delle app noti come il pinning
• Tolleranza operativa per interruzioni

FAQ sul traffico crittografato

Cos’è il traffico crittografato in termini semplici?

Il traffico crittografato utilizza la crittografia per proteggere il traffico di rete da intercettazioni e modifiche malevole. TLS è il protocollo più comune per la crittografia del traffico ed è la differenza tra il traffico web HTTP e HTTPS. Sebbene la crittografia protegga l’integrità, la riservatezza e l’autenticità dei dati, non garantisce che i dati crittografati siano benigni.

Il traffico crittografato è lo stesso di HTTPS?

HTTPS è una forma comune di traffico crittografato, che utilizza TLS per proteggere il traffico HTTP. Tuttavia, ci sono anche altre forme di traffico crittografato, comprese le VPN e altri protocolli di rete protetti da TLS.

Cos’è TLS e perché le persone continuano a dire SSL?

TLS è il successore di SSL, che è insicuro. Le persone possono ancora dire SSL o SSL/TLS riferendosi a TLS per abitudine o riconoscimento di questo lascito.

Perché la crittografia può creare punti ciechi nella sicurezza?

La crittografia può creare punti ciechi nella sicurezza poiché gli strumenti di sicurezza non possono leggere i dati crittografati per cercare malware, contenuti di phishing, perdite di dati e altre minacce. Di conseguenza, le organizzazioni potrebbero dover fare affidamento su metadati non crittografati e segnali comportamentali per identificare connessioni sospette o implementare la decrittazione del traffico di rete.

I team possono analizzare il traffico crittografato senza decrittarlo?

Analizzare il traffico di rete crittografato senza decrittarlo include l’uso di metadati, comportamento del flusso, telemetria degli endpoint e intelligence sulle minacce per dedurre il rischio senza leggere il contenuto. Ad esempio, un’organizzazione potrebbe dedurre che il traffico verso un indirizzo IP noto come dannoso è malevolo senza leggere i suoi contenuti. Tuttavia, alcuni controlli richiedono visibilità del payload, quindi i metodi non di decrittazione non sono un sostituto completo.

Quando è appropriata l’ispezione basata sulla decrittazione e quali sono i maggiori rischi?

L’ispezione basata sulla decrittazione può essere appropriata per categorie ad alto rischio come traffico web sconosciuto, download di file o accesso a sistemi sensibili, quando sono in atto politiche e governance. Tuttavia, la decrittazione introduce rischi, come preoccupazioni relative alla privacy e alla conformità, prestazioni degradate e malfunzionamenti delle applicazioni se sono in atto soluzioni di pinning dei certificati o simili. Le organizzazioni dovrebbero essere selettive riguardo al traffico che decrittano, testare su applicazioni critiche e mantenere un chiaro processo di bypass ed eccezione.

Ispezione del traffico crittografato con Cato

Il Cato SASE Cloud include una rete globale di PoP SASE costruita attorno al Single Pass Cloud Engine (SPACE) di Cato. Cato converte le funzioni di sicurezza di Security Service Edge (SSE) — inclusi FWaaS, CASB, SWG e DLP — in un’unica soluzione, e SPACE consente a queste funzioni di sicurezza di accedere ai dati decrittografati all’interno di un’unica fase di decrittazione e reencryption del traffico. Quando è necessaria la decrittazione del traffico, questo minimizza i potenziali impatti sulle prestazioni e sulla latenza.

Cato offre anche accesso a dati contestuali ricchi sui flussi di rete. Questo consente alle organizzazioni di gestire il rischio di sicurezza senza ricorrere alla crittografia, ottimizzando ulteriormente le prestazioni e la sicurezza della rete. Per saperne di più su come Cato gestisce il traffico di rete crittografato, prenota una demo.