Crittografia e traffico cifrato

Sì, a partire dai metadati: il traffico cifrato non viene mai decifrato. NetSenX esamina i metadati dei flussi e alcuni campi di protocollo — tempi, volumi, destinazioni e handshake TLS — così beaconing e trasferimenti anomali restano visibili senza violare la cifratura né leggere i contenuti.

Sì, a partire dai metadati. Tempi, volumi, destinazioni e handshake TLS restano visibili quando il contenuto è cifrato, quindi il beaconing verso un server C2 e i trasferimenti anomali si possono rilevare senza violare la cifratura. Resta invisibile il contenuto della sessione.

I metadati del flusso (chi si connette con chi, quando, con quale frequenza e quanti dati si spostano) e alcuni campi di protocollo: il nome del server e i parametri dell'handshake TLS, oltre alle risposte alle query DNS. Non decifra mai la sessione e non ne legge il contenuto cifrato.

Per molte no. Chi parla con chi, quando, quanto spesso e quanto, insieme all'handshake TLS non cifrato e alle risposte DNS, resta visibile senza decifrare. Basta per vedere il beaconing verso un server di comando e controllo, le scansioni, il movimento laterale tra host interni e i caricamenti insoliti, cioè passi che la maggior parte delle intrusioni compie prima di fare danni. Decifrare serve per vedere il contenuto, come un file malevolo dentro un download o il testo di un comando, e ha dei costi: un proxy di intercettazione che detiene chiavi e dati in chiaro, un certificato aziendale su ogni dispositivo gestito, app che smettono di funzionare, questioni di privacy e di rappresentanza dei lavoratori e punti ciechi sui dispositivi non gestiti. Molte aziende ottengono di più dalla protezione degli endpoint per file e processi su ogni macchina, insieme al rilevamento di rete per il comportamento di tutti i dispositivi. NetSenX non decifra mai il traffico: i rilevamenti di base funzionano in ogni piano, le impronte TLS dal piano Starter dove l'agente cattura i pacchetti.

La decifratura dà visibilità sui contenuti, ma richiede un punto di intercettazione che custodisce chiavi, un certificato di intercettazione su ogni dispositivo e la gestione di contenuti decifrati che possono includere dati personali. Da TLS 1.3 un sensore passivo non può più decifrare le sessioni con una copia della chiave privata del server.

Più di quanto si pensi. Per ispezionare HTTPS, il firewall o il proxy termina ogni connessione, la decifra, la esamina e apre una nuova connessione cifrata verso il server reale, presentando un proprio certificato firmato da una radice aziendale installata su ogni dispositivo gestito. Effetti collaterali: app con pinning dei certificati, molti programmi di aggiornamento, alcune app bancarie e sanitarie e parti dei servizi cloud rifiutano il certificato sostitutivo, quindi le liste di eccezioni crescono di continuo; dispositivi non gestiti, ospiti e macchine non si possono ispezionare affatto; il proxy diventa un unico punto che detiene traffico in chiaro, dati personali compresi, il che solleva questioni di GDPR e di rappresentanza dei lavoratori; i proxy datati potrebbero non supportare le funzioni recenti di TLS o i nuovi gruppi ibridi post-quantistici e indebolire le connessioni in silenzio; e l'ispezione costa prestazioni. Ha comunque il suo posto, per esempio per analizzare i download sui portatili gestiti. Ma molte minacce sono visibili anche senza. È l'approccio di NetSenX: non decifra mai e lavora su metadati e handshake non cifrato.

Solo sulle parti non cifrate, a meno di decifrare. L'ispezione approfondita dei pacchetti (DPI) significa leggere oltre le intestazioni, dentro il contenuto. Con TLS il contenuto è cifrato, quindi le firme classiche che cercano un file o un comando malevolo nel flusso non corrispondono più. Restano leggibili i messaggi di handshake non cifrati, con versione di TLS, scelte di cifrario e di scambio di chiavi, un'impronta del client e di solito il nome del server, e le risposte DNS che hanno preceduto la connessione. Insieme ai metadati di flusso, cioè chi, quando, quanto spesso e quanto, basta per molti rilevamenti: beaconing verso un server di comando e controllo, scansioni, movimento laterale e caricamenti insoliti. Per vedere il contenuto serve un proxy di intercettazione che decifri e cifri di nuovo il traffico, con costi e rischi propri. NetSenX legge i campi dell'handshake dove il suo agente cattura i pacchetti, su Linux o come sensore SPAN/TAP, non nella modalità di base su macOS, e non decifra mai il traffico.

Spesso sì, perché un malware deve comportarsi in certi modi per essere utile, e quel comportamento si vede nei flussi. I record di flusso descrivono ogni connessione: sorgente e destinazione, porte, ora di inizio, durata, byte e pacchetti in ciascuna direzione. Un dispositivo compromesso che contatta il proprio server di controllo a intervalli regolari produce un ritmo riconoscibile, il beaconing; uno che esplora la rete tocca molti host e porte interni in poco tempo, cioè scansione e movimento laterale; uno che ruba dati invia molto più del solito, spesso di notte. Nulla di questo richiede di decifrare, e la ricerca sull'analisi del traffico cifrato mostra da anni che gli schemi di tempo e dimensione portano molta informazione. I limiti: una singola connessione a un noto servizio cloud può sembrare innocua, e gli attaccanti pazienti cercano di confondersi. Per questo l'analisi dei flussi funziona meglio rispetto a una linea di base di ciò che è normale per ogni dispositivo. NetSenX rileva beaconing, scansioni, movimento laterale e volumi in uscita insoliti in ogni piano, anche Free.

Non il contenuto, ma più cose su di esso di quanto si pensi. La cifratura nasconde parole, file e battiture, eppure dimensione, tempi e direzione dei pacchetti lasciano trapelare schemi: una videochiamata, un grande caricamento, una sessione di desktop remoto e un aggiornamento software hanno ciascuno una forma riconoscibile. I ricercatori mostrano da anni che questa analisi del traffico può identificare, con precisione variabile, i siti visitati o le applicazioni usate, anche attraverso una VPN. Per la difesa è utile: così un sensore di rete distingue una sessione interattiva da un contatto automatico, o nota un server che all'improvviso invia gigabyte, senza decifrare nulla. Per la privacy è un promemoria che cifratura non significa invisibilità. Ciò che l'analisi del traffico non può fare è leggere un messaggio, vedere quale file è stato caricato o sapere che cosa qualcuno ha scritto in un chatbot di IA. NetSenX usa metadati di flusso e l'handshake non cifrato, non decifra mai le sessioni e non ricostruisce contenuti.

Possono esserlo. Nella causa Breyer (C-582/14, 19 ottobre 2016) la Corte di giustizia dell'UE ha stabilito che un indirizzo IP dinamico può costituire un dato personale. NetSenX pubblica un accordo sul trattamento dei dati ai sensi dell'articolo 28 del GDPR e conserva i dati dei clienti nell'UE.

Sì. HTTPS significa che la connessione è cifrata e che il server ha un certificato valido per il nome nella barra degli indirizzi; non dice nulla sulla sicurezza del sito o dei suoi download. Gli attaccanti usano HTTPS con la stessa normalità di tutti, perché i certificati sono gratuiti e automatici, e buona parte del phishing e della diffusione di malware passa da lì. Il lucchetto La protegge da chi legge o altera il traffico lungo il percorso, non dal contenuto all'altra estremità. La protezione dai download malevoli viene dalla protezione dell'endpoint sul dispositivo, dai filtri del browser e della posta, dal software aggiornato e dal limitare chi può installare programmi. Sul lato rete, la cifratura nasconde il file ma non il comportamento che di solito segue un'infezione: un dispositivo che all'improvviso contatta una nuova destinazione a intervalli regolari, scansiona host interni o invia volumi di dati insoliti. NetSenX rileva questi schemi in ogni piano, dai metadati di flusso e senza decifrare il traffico.

Solo se si riesce a far fidare il client dell'intercettatore. Un attacco man in the middle su HTTPS richiede un certificato che il client accetti per il nome di destinazione, un utente che ignori l'avviso o un'applicazione che non verifichi correttamente i certificati. Le aziende lo fanno di proposito con proxy di ispezione TLS, installando un proprio certificato radice sui dispositivi gestiti. Gli attaccanti tentano lo stesso inserendo un falso certificato radice tramite malware, convincendo gli utenti ad accettare gli avvisi o sfruttando app con controlli dei certificati difettosi. Difese: non abitui mai il personale a ignorare gli avvisi sui certificati, controlli quali certificati radice sono installati sui dispositivi aziendali, tenga aggiornate le app e usi HTTP Strict Transport Security (HSTS) sui propri siti perché i browser rifiutino le connessioni in chiaro. Il pinning dei certificati in alcune app rifiuta qualsiasi intercettatore, compreso il Suo proxy. In TLS 1.3 il certificato del server è cifrato, quindi un sensore di rete passivo non può verificare chi lo ha emesso; questo controllo spetta al dispositivo o ai log del proxy.

Quando un programma apre una connessione TLS, il suo primo messaggio elenca le versioni, i cifrari e le estensioni che supporta, in un ordine caratteristico. Un'impronta come JA4 condensa quel messaggio in una breve stringa, così lo stesso software client si riconosce tra una connessione e l'altra senza decifrare nulla. Aiuta a individuare client insoliti, come uno script che si spaccia per un browser. NetSenX calcola le impronte TLS dall'handshake a partire dal piano Starter, con un'implementazione propria. L'handshake è visibile solo dove l'agente cattura i pacchetti: su Linux o come sensore su una porta SPAN o TAP, non nella modalità di base usata su macOS.

Entrambi creano un'impronta del lato client di un handshake TLS, ma JA4 tiene conto del comportamento dei browser moderni. JA3, pubblicato nel 2017, calcola un hash dei campi del ClientHello nell'ordine in cui compaiono. Dall'inizio del 2023 Chrome ha iniziato a mescolare l'ordine delle estensioni TLS a ogni connessione, il che cambia ogni volta il valore JA3 e lo rende molto meno utile per riconoscere i browser. JA4, pubblicato nel 2023, ordina i campi prima dell'hash, aggiunge la versione di TLS, il trasporto (TCP o QUIC) e il primo protocollo applicativo offerto, e produce una stringa leggibile le cui parti si confrontano separatamente. Nessuno dei due dimostra da solo un intento malevolo: molti programmi condividono un'impronta e un malware può imitare un browser. Servono a individuare un client che non si addice al dispositivo, come uno script che si spaccia per browser su un server. NetSenX calcola le impronte TLS dal piano Starter, con un'implementazione propria, dove il suo agente cattura i pacchetti: su Linux o come sensore SPAN/TAP, non nella modalità di base su macOS.

Server Name Indication (SNI) è un campo del ClientHello TLS in cui il client indica il sito che vuole raggiungere, come login.example.com, perché molti siti condividono un indirizzo IP e il server deve sapere quale certificato presentare. Viene inviato prima che inizi la cifratura, quindi chiunque sul percorso può leggerlo. Per il monitoraggio è uno dei campi più utili del traffico cifrato: dà un nome al servizio dietro un indirizzo IP, il che aiuta a distinguere un assistente di IA, un servizio di condivisione file o un'applicazione aziendale nota da un server sconosciuto, senza leggere alcun contenuto. Anche la maggior parte dei filtri web e molti firewall si basano su di esso. Due fattori ne riducono il valore: le connessioni dirette a un indirizzo IP non portano un nome significativo, e Encrypted Client Hello (ECH) nasconde il nome reale dietro un nome pubblico di facciata. Allora contano di più le risposte DNS e la storia di ogni destinazione. NetSenX legge il nome del server dall'handshake dove il suo agente cattura i pacchetti, su Linux o come sensore SPAN/TAP.

ECH è un'estensione di TLS che cifra la parte sensibile del ClientHello, compreso il vero nome del server, con una chiave pubblica che il sito pubblica nel DNS. Sulla rete un osservatore vede solo un ClientHello esterno con un nome pubblico condiviso, di solito quello della rete di distribuzione dei contenuti che ospita il sito, invece del sito reale. È stato progettato per la privacy: impedire a chiunque sul percorso, dal Wi-Fi di un bar al provider internet, di sapere quale sito visita. I principali browser lo supportano e alcune grandi reti di distribuzione dei contenuti lo offrono, quindi una parte del traffico web lo usa già, mentre la maggior parte dei server aziendali e interni no. ECH di solito si accompagna al DNS cifrato, altrimenti il nome trapelerebbe comunque dalla query DNS. Certificato e contenuto della sessione erano già cifrati con TLS 1.3; ECH chiude uno degli ultimi campi leggibili. Per i team di sicurezza significa meno nomi e più affidamento sul comportamento.

In parte. Con ECH un sensore non vede più il vero nome del server nell'handshake, quindi regole basate sui nomi, filtri web e semplici elenchi di shadow IT perdono precisione per i siti che lo usano. Resta molto: l'indirizzo IP di destinazione e chi lo gestisce, il nome pubblico esterno, di solito quello di una grande rete di distribuzione dei contenuti, le risposte DNS quando il DNS non è cifrato da un capo all'altro, tempi, volume e direzione di ogni flusso e l'impronta del client. I rilevamenti comportamentali come beaconing, scansioni, movimento laterale e caricamenti insoliti non dipendono dal nome del server e continuano a funzionare. Il traffico interno ne risente raramente, perché i server interni di rado pubblicano chiavi ECH. Sui dispositivi gestiti può intervenire: li faccia puntare al proprio resolver DNS e usi le policy aziendali del browser, che permettono di controllare ECH e DNS cifrato. La visibilità per nome dei servizi di IA o di condivisione file diventa meno completa per i siti dietro ECH con qualsiasi sensore di rete, NetSenX compreso.

Riducono ciò che vedono i firewall datati, ma non rendono invisibile il traffico. QUIC (RFC 9000, 2021) è il trasporto su cui poggia HTTP/3. Usa la porta UDP 443 e cifra quasi tutto, compresa buona parte di ciò che TCP lasciava leggibile, come numeri di pacchetto e conferme. I suoi primi pacchetti portano un ClientHello TLS 1.3 protetto solo da chiavi che chiunque può ricavare, quindi un sensore che comprende QUIC può ancora leggere il nome del server e i parametri dell'handshake. Firewall e proxy costruiti per TCP spesso non riescono affatto a ispezionare QUIC. Nelle aziende che si affidano all'ispezione TLS o al filtraggio web è prassi bloccare la porta UDP 443, così i browser tornano a HTTP/2 su TCP senza che gli utenti se ne accorgano. Senza una regola del genere, QUIC appare semplicemente come flussi UDP con tempi e volumi come qualsiasi altro traffico, e i rilevamenti basati sui flussi, come il beaconing e i volumi di caricamento insoliti, restano validi. Verifichi se il Suo firewall riporta il traffico QUIC prima di darlo per coperto.

Può nascondere le interrogazioni DNS, non le connessioni che seguono. DNS over HTTPS (DoH, RFC 8484) e DNS over TLS (DoT, RFC 7858) cifrano le domande che un dispositivo pone al proprio resolver. Se browser o app usano un resolver DoH esterno, il server DNS aziendale e i suoi log non vedono più quali nomi vengono risolti, il che indebolisce il filtraggio basato sul DNS e le indagini. Un malware può usare DoH per lo stesso motivo. Le connessioni verso le destinazioni effettive attraversano comunque la rete con indirizzi IP, tempi e volumi, e spesso con il nome del server nell'handshake TLS. Passi pratici: usi un proprio resolver, o quello di un fornitore, che supporti il DNS cifrato e lo faccia usare ai dispositivi gestiti; impedisca con le policy di browser e sistema operativo l'uso di altri resolver; e cerchi i dispositivi che parlano direttamente con servizi DoH pubblici. DoT è facile da individuare perché usa la porta 853; DoH sembra normale HTTPS. NetSenX genera allarmi sul tunneling DNS; non filtra né blocca il DNS.

Su una macchina che controlla, il modo più semplice è far scrivere al client le chiavi di sessione in un file e caricarlo in Wireshark. I browser e molti strumenti a riga di comando basati su OpenSSL o NSS rispettano la variabile d'ambiente SSLKEYLOGFILE: la imposti, riproduca il problema mentre cattura con Wireshark o tcpdump, poi indichi il file delle chiavi nelle impostazioni TLS di Wireshark. Funziona anche con TLS 1.3, dove la chiave privata del server non basta più. Su un server che gestisce, alcuni server web e proxy possono registrare le chiavi, oppure può provare su una copia di test con la registrazione attiva. Tratti i file delle chiavi come password: chi ha il file e la cattura può leggere il traffico, quindi cancelli entrambi alla fine e non li raccolga mai dai dispositivi di altre persone senza una base chiara e senza che lo sappiano. Nel monitoraggio quotidiano decifrare serve raramente: metadati di flusso e handshake non cifrato rispondono alla maggior parte delle domande su chi parla con chi e come.

In TLS 1.3 serve un'andata e ritorno prima che i dati inizino a fluire. Il client invia un ClientHello con le versioni di TLS, le suite di cifratura e i gruppi di scambio di chiavi che supporta, una quota di chiave per il gruppo preferito e di solito il nome del server che vuole raggiungere (SNI). Il server risponde con un ServerHello che sceglie versione, cifrario e gruppo, e con la propria quota di chiave. Dalle due quote entrambe le parti ricavano lo stesso segreto e da quel momento tutto è cifrato, compreso il certificato del server e la prova che possiede la chiave privata corrispondente. Il client verifica il certificato rispetto alle autorità di cui si fida e iniziano i dati applicativi. ClientHello e ServerHello viaggiano in chiaro, ed è per questo che un sensore passivo vede la versione di TLS, il gruppo di scambio di chiavi scelto, per esempio X25519 classico o X25519MLKEM768 ibrido, e un'impronta del client senza decifrare nulla. Con Encrypted Client Hello anche parte del ClientHello, nome del server compreso, viene nascosta.

TLS 1.3 (RFC 8446, 2018) è più veloce ed elimina le opzioni deboli alla base della maggior parte degli attacchi passati a TLS. Completa l'handshake in un'andata e ritorno invece di due. Mantiene solo scambi di chiavi con forward secrecy, quindi registrare il traffico e rubare in seguito la chiave privata del server non permette più di decifrare le sessioni passate. Abbandona cifrari e modalità datati come RC4, 3DES, le suite in modalità CBC e lo scambio di chiavi RSA statico, lasciando un breve elenco di cifrari autenticati moderni. E cifra una parte maggiore dell'handshake, compreso il certificato del server. Per il monitoraggio ne seguono due conseguenze. Un dispositivo passivo non può più decifrare le sessioni con una copia della chiave privata del server, quindi l'ispezione richiede ora un proxy di intercettazione attivo. E in chiaro si vede meno: il certificato è nascosto, mentre i messaggi hello, il gruppo scelto e il nome del server, salvo l'uso di Encrypted Client Hello, restano visibili. Preferisca TLS 1.3 ovunque e mantenga TLS 1.2 solo con suite robuste per i client più vecchi.

Sì. Entrambi sono formalmente deprecati dall'IETF dalla RFC 8996 (marzo 2021), i principali browser non li accettano più e si basano su vecchie funzioni di hash e costruzioni di cifratura con debolezze note. Se sono ancora attivi su un server, il rischio non è tanto un attacco diretto quanto una via di downgrade, e un segno di trascuratezza che revisori, assicuratori e scanner segnaleranno. Prima di disattivarli, scopra chi li usa ancora: vecchie stampanti, scanner, apparati industriali, applicazioni legacy e client embedded sono i soliti sospetti, e disattivarli senza verificare può fermare una linea di produzione o un terminale di pagamento. Guardi i log dei server che registrano la versione di TLS, passi uno scanner esterno sui servizi pubblici e, dentro la rete, osservi le versioni di TLS negli handshake. Poi li disattivi, o isoli in un segmento dedicato ciò che non si può aggiornare, con un piano di sostituzione. Lo stesso inventario servirà più avanti per il lavoro post-quantistico.

Tutto ciò che non offre forward secrecy o cifratura autenticata, e tutto ciò che compare nelle vecchie liste. In pratica: disattivi RC4, che la RFC 7465 vieta in TLS, 3DES e gli altri cifrari a blocchi da 64 bit, i cifrari export e NULL, lo scambio di chiavi RSA statico e le suite in modalità CBC con SHA-1 se i Suoi client lo consentono. Mantenga le suite di TLS 1.3, AES-GCM e ChaCha20-Poly1305, e per TLS 1.2 usi lo scambio ECDHE con AES-GCM o ChaCha20-Poly1305. Si affidi a guide di configurazione pubblicate invece di inventarne di proprie: le raccomandazioni Server Side TLS di Mozilla e le linee guida tecniche di agenzie come la tedesca BSI offrono profili collaudati per client moderni e meno recenti. Prima di modificare un server di produzione, verifichi quali client si collegano e che cosa offrono, dai log del server o da una vista degli handshake, per non escludere un vecchio dispositivo. Poi ripeta il test dall'esterno con uno scanner TLS e attivi il gruppo ibrido X25519MLKEM768 dove il Suo software lo supporta.

La forward secrecy significa che ogni sessione usa una chiave nuova e temporanea, poi scartata, così che rubare in seguito la chiave privata a lungo termine di un server non permetta di decifrare le sessioni registrate prima. Deriva dagli scambi di chiavi effimeri come ECDHE o X25519: la chiave a lungo termine dimostra solo l'identità del server, mentre la chiave di sessione nasce da valori usa e getta scelti da entrambe le parti. Le vecchie configurazioni TLS con scambio di chiavi RSA statico non l'avevano, quindi una sola chiave rubata poteva aprire anni di traffico registrato. TLS 1.3 la rende obbligatoria, e i server TLS 1.2 ben configurati la offrono anch'essi. Spiega anche perché «harvest now, decrypt later» riguarda lo scambio di chiavi: la forward secrecy protegge da un futuro furto della chiave, ma non da un futuro computer quantistico in grado di rompere lo stesso scambio effimero su curve ellittiche. Lo scambio di chiavi ibrido post-quantistico mantiene la forward secrecy e aggiunge la protezione mancante. Verifichi i Suoi server con uno scanner TLS: ogni suite offerta dovrebbe averla.

La crittografia trasforma dati leggibili in dati rimescolati che solo chi ha la chiave giusta può riportare in chiaro. Il metodo, detto algoritmo, è pubblico; il segreto è la chiave. Una buona crittografia significa che senza la chiave nemmeno un computer potente può recuperare i dati in un tempo utile. La usa ogni giorno: HTTPS sui siti, la VPN verso l'ufficio, le app di messaggistica, la cifratura del disco su portatili e telefoni, i backup. Protegge i dati in transito da chiunque possa ascoltare la rete e i dati archiviati da chiunque rubi il disco. Non protegge i dati da chi ha già la chiave o controlla un dispositivo su cui i dati vengono decifrati, come un malware su un portatile con la sessione aperta. Per questo la crittografia affianca il controllo degli accessi, gli aggiornamenti e il monitoraggio, senza sostituirli. Un sensore di rete vede che avvengono connessioni cifrate, con i loro metadati, ma non il loro contenuto.

La crittografia simmetrica usa un'unica chiave condivisa per chiudere e aprire; quella asimmetrica, o a chiave pubblica, usa una coppia: una chiave pubblica che chiunque può conoscere e una chiave privata che ha solo il titolare. Gli algoritmi simmetrici come AES sono veloci e cifrano quasi tutti i dati reali. Il loro punto debole è condividere la chiave in modo sicuro. Lo risolvono i metodi a chiave pubblica come RSA, Diffie-Hellman su curve ellittiche e i loro successori post-quantistici: due parti che non si sono mai incontrate possono concordare una nuova chiave simmetrica su una rete aperta, e una chiave privata può firmare dati in modo che chiunque abbia la chiave pubblica possa verificarli. I protocolli reali combinano entrambe. Una connessione TLS usa la crittografia a chiave pubblica nell'handshake per concordare una chiave e dimostrare l'identità del server, poi passa ad AES o ChaCha20 per i dati. Questa divisione spiega anche la questione quantistica: l'algoritmo di Shor minaccia la parte a chiave pubblica, mentre la crittografia simmetrica con chiavi da 256 bit resta solida.

Dipende dal tipo di algoritmo, perché le lunghezze non sono confrontabili tra tipi diversi. Nella crittografia simmetrica AES-128 è ancora considerato robusto e AES-256 offre un margine in più, anche contro i futuri computer quantistici; usi 256 bit per i dati che devono restare segreti per molti anni. Per RSA, 2048 bit sono oggi il minimo abituale, e agenzie come la tedesca BSI raccomandano almeno 3000 bit per una protezione più lunga. Le chiavi su curve ellittiche sono molto più corte a parità di robustezza: una curva da 256 bit come P-256 o X25519 equivale grosso modo a un RSA di circa 3000 bit. Per l'hashing usi SHA-256 o superiore. Due avvertenze contano più dei numeri. La lunghezza non serve se la chiave è generata male, conservata in uno script o mai cambiata. E RSA e curve ellittiche di qualsiasi lunghezza cadono davanti a un grande computer quantistico, per cui il loro sostituto a lungo termine sono gli algoritmi post-quantistici, non chiavi più lunghe. Per i valori esatti segua le linee guida aggiornate dell'agenzia nazionale.

Una funzione di hash trasforma qualsiasi quantità di dati in un'impronta breve di lunghezza fissa, come l'output a 256 bit di SHA-256. Lo stesso input dà sempre lo stesso hash, una minima modifica ne dà uno completamente diverso, e nessuno può risalire dall'hash all'input né trovare due input con lo stesso hash. Per questo gli hash servono a verificare che un download o un backup non sia cambiato, per le firme digitali, che firmano l'hash di un documento, per conservare le password in modo sicuro e per i controlli di integrità dentro TLS. Funzioni datate hanno ceduto: MD5 e SHA-1 sono rotte per gli usi di sicurezza, e nel 2017 è stata dimostrata pubblicamente una collisione di SHA-1, quindi le tratti come obsolete ovunque compaiano ancora, per esempio in vecchi certificati o controlli di file. SHA-256, SHA-384 e SHA-3 sono le scelte attuali. Un hash non è cifratura: non c'è chiave né nulla da decifrare. I computer quantistici indeboliscono le funzioni di hash solo moderatamente.

No, e per le password l'hash è la scelta giusta. La cifratura è reversibile con una chiave, quindi chi ruba le password cifrate insieme alla chiave le recupera tutte. Un hash non si può invertire, perciò il sistema conserva solo l'hash e lo confronta all'accesso. Le normali funzioni di hash veloci come SHA-256 restano però una cattiva scelta per le password, perché chi ruba un database può provare quantità enormi di tentativi al secondo con le schede grafiche. Usi una funzione pensata per le password, volutamente lenta e con un salt casuale per utente: Argon2id, scrypt o bcrypt, come raccomanda la guida OWASP sulla conservazione delle password. Se un fornitore o una vecchia applicazione conserva le password cifrate, o con un semplice hash MD5 o SHA-1, lo tratti come un rilievo da correggere. Per il Suo personale i vantaggi maggiori sono altrove: autenticazione a più fattori (MFA), un gestore di password e il blocco delle password riutilizzate. Un sensore di rete non vede come un server conserva le password; questo controllo spetta a una revisione dell'applicazione.

Una firma digitale è un valore calcolato dai dati con una chiave privata, che chiunque abbia la chiave pubblica corrispondente può verificare. Se la verifica riesce, sono dimostrate due cose: i dati provengono dal titolare di quella chiave privata e non sono cambiati da quando sono stati firmati. Le firme proteggono molto di ciò su cui fa affidamento senza accorgersene: aggiornamenti software e driver, i certificati TLS che dimostrano l'identità di un sito, PDF firmati e fatture elettroniche, posta firmata con S/MIME e il codice rilasciato dai Suoi sviluppatori. Nell'UE le firme elettroniche qualificate ai sensi del regolamento eIDAS hanno anche valore legale. Una firma è affidabile quanto la sua chiave privata: se la chiave viene rubata, un attaccante può firmare un malware che sembra autentico, ed è per questo che le chiavi di firma vanno tenute in moduli di sicurezza hardware o archivi protetti in modo analogo, utilizzabili da poche persone. Le firme attuali usano RSA o curve ellittiche, che un grande computer quantistico romperebbe; i loro sostituti post-quantistici sono ML-DSA e SLH-DSA.

Un certificato TLS è un documento firmato che lega una chiave pubblica a un nome, come www.example.com, così che un browser o un client possa verificare di parlare con il server vero e non con un impostore. La firma viene da un'autorità di certificazione (CA) di cui il client si fida già, di solito tramite una catena: una CA radice, una CA intermedia e poi il certificato del server. Durante l'handshake il server presenta il certificato e dimostra di possedere la chiave privata corrispondente. I certificati hanno una scadenza e possono essere revocati. Ciò che un certificato non dimostra è che il sito sia sicuro o onesto: un sito di phishing può avere un certificato perfettamente valido, perché le CA verificano soprattutto il controllo del dominio, non l'azienda che c'è dietro. Nelle aziende una CA interna rilascia spesso i certificati per server, VPN e dispositivi. Tenga un inventario di tutti i certificati con responsabili e scadenze; quelli dimenticati causano interruzioni e nascondono chiavi deboli.

I client smettono di fidarsi del server: i browser mostrano un avviso a tutta pagina, e app, API, client VPN e dispositivi di solito rifiutano del tutto la connessione. Per gli utenti sembra un'interruzione, e in pratica lo è: pagine di pagamento, portali clienti, server di posta e collegamenti tra macchine possono smettere di funzionare al momento della scadenza, spesso di notte o nel fine settimana. I certificati scaduti abituano anche il personale a ignorare gli avvisi, esattamente ciò che vorrebbe un attaccante che intercetta il traffico. La soluzione è un processo, non l'eroismo: un inventario di ogni certificato con responsabile e scadenza, avvisi con largo anticipo e rinnovo automatico tramite il protocollo ACME (RFC 8555) ovunque la piattaforma lo consenta. Non dimentichi i certificati dentro appliance, stampanti, servizi interni e firma del codice, che gli scanner esterni non vedono mai. Osservare gli handshake TLS sulla rete interna aiuta a trovare server che nessuno ha elencato, anche se in TLS 1.3 il certificato stesso è cifrato e va verificato sul server.

Perché durate più brevi limitano i danni di una chiave rubata o di un certificato emesso per errore, e spingono tutti ad automatizzare il rinnovo. Nell'aprile 2025 il CA/Browser Forum, l'organismo di autorità di certificazione e produttori di browser che fissa le regole per i certificati TLS pubblici, ha approvato la votazione SC-081: la durata massima scende da 398 a 200 giorni dal 15 marzo 2026, a 100 giorni dal 15 marzo 2027 e a 47 giorni dal 15 marzo 2029. Le regole valgono per i certificati pubblicamente riconosciuti, non per quelli emessi dalla propria CA interna. Per un'azienda che rinnova ancora i certificati a mano una volta l'anno, il carico di lavoro cambia: i rinnovi diventano frequenti e i processi manuali falliranno. La risposta è automatizzare con ACME (RFC 8555) o con gli strumenti del fornitore, tenere un inventario di ogni certificato pubblico e di dove è installato, compresi bilanciatori e appliance, e monitorare le scadenze. Lo consideri un esercizio di agilità crittografica: la stessa disciplina aiuterà nella transizione post-quantistica.

Non perché sono autofirmati, ma per ciò che di solito li accompagna. Un certificato autofirmato cifra bene come qualsiasi altro; il problema è la fiducia. I client non possono verificarlo rispetto a un'autorità nota, quindi utenti e amministratori imparano a ignorare gli avvisi o a disattivare la verifica negli script, e la stessa abitudine lascia passare inosservata una vera intercettazione. I certificati autofirmati sulle appliance hanno spesso chiavi deboli o predefinite, nessun controllo delle scadenze e nessun responsabile. Lo schema migliore è un'autorità di certificazione interna, che emetta in modo automatico dove possibile, con il certificato radice distribuito sui dispositivi gestiti e un inventario di ogni certificato e della sua scadenza. Per i dispositivi forniti solo con certificati autofirmati, come stampanti o controllori, sostituisca il certificato dove il dispositivo lo consente e tenga il dispositivo in un segmento ad accesso limitato. I certificati autofirmati vanno anche nel Suo inventario post-quantistico: ognuno ha un tipo e una dimensione di chiave che un giorno andranno cambiati.

Il TLS reciproco significa che entrambe le parti di una connessione presentano certificati: il server dimostra la propria identità al client e il client al server. Nel normale HTTPS solo il server ha un certificato, e l'utente dimostra chi è in seguito con una password o un token. Con mTLS il client ha bisogno di una chiave privata e di un certificato emesso da un'autorità di cui il server si fida, difficile da sottrarre con il phishing e facile da revocare. È comune tra servizi in architetture a microservizi, per le API tra aziende, per l'identità dei dispositivi in IoT e OT e in alcuni prodotti di accesso remoto zero trust. I costi sono la gestione dei certificati su larga scala, cioè emettere, ruotare e revocare i certificati client, e la diagnosi quando qualcosa scade. In rete, mTLS sembra normale TLS. In TLS 1.3 il certificato client è cifrato, quindi un sensore passivo vede che la connessione esiste e i suoi parametri di handshake, non quale certificato client è stato usato.

Cifra il traffico tra il Suo dispositivo e il gateway VPN, non l'intero percorso fino alla destinazione. Dopo il gateway il traffico prosegue verso la rete dell'ufficio o internet protetto solo da ciò che usa l'applicazione stessa, come HTTPS. Una VPN aziendale protegge quindi il personale sul Wi-Fi di hotel o bar dalle intercettazioni locali e dà accesso ai sistemi interni; non rende sicura un'applicazione interna non cifrata e non nasconde nulla alla rete aziendale che riceve il traffico. Lo split tunnelling manda nella VPN solo una parte del traffico e il resto direttamente, il che aiuta le prestazioni ma significa che il monitoraggio aziendale ne vede solo una parte. Un servizio VPN commerciale sposta la Sua fiducia dal provider internet al fornitore della VPN. I gateway VPN sono essi stessi bersagli frequenti e richiedono aggiornamenti rapidi e autenticazione a più fattori (MFA). In rete i tunnel VPN sono visibili come connessioni verso il gateway, con tempi e volumi, non con il loro contenuto.

Combini una scansione attiva con l'osservazione passiva, perché ciascuna trova ciò che sfugge all'altra. Una scansione autorizzata dei Suoi intervalli di indirizzi sulla porta 22 e sulle altre porte SSH comuni, con uno strumento come Nmap, elenca ogni host che risponde e la versione software che dichiara. Controlli le console cloud e i record DNS per i server fuori dagli intervalli dell'ufficio. L'osservazione passiva aggiunge ciò che le scansioni non vedono: SSH su porte insolite, server raggiungibili solo da certi segmenti e come SSH viene usato davvero, cioè quali client si collegano a quali server e quando. Poi esamini l'elenco con i responsabili: ogni server ha bisogno di una persona designata, di un motivo per esistere e di un calendario di aggiornamenti, e ciò che nessuno rivendica va spento dopo un periodo di preavviso. Limiti SSH alle reti degli amministratori o a un jump host e usi chiavi invece di password. NetSenX genera allarmi in ogni piano quando un host inizia a raggiungere molti host interni su porte di amministrazione come SSH, perché è così che appaiono scansioni e movimento laterale.

Parta dalla versione che ogni server dichiara, poi la confermi con lo stato delle patch del fornitore, perché la sola dichiarazione può trarre in inganno. Ogni server SSH invia prima di tutto una stringa di identificazione come SSH-2.0-OpenSSH_9.6p1, che uno scanner o una semplice connessione mostrano. Confronti quella versione con l'intervallo indicato nel bollettino. Per regreSSHion (CVE-2024-6387), per esempio, il bollettino pubblicato da Qualys il 1° luglio 2024 indicava OpenSSH da 8.5p1 fino a 9.8p1 esclusa, su Linux basato su glibc. Poi verifichi la versione del pacchetto su ogni server: le distribuzioni Linux spesso riportano le correzioni di sicurezza in un numero di versione più vecchio, quindi un server che dichiara una versione colpita può essere già corretto, e fa fede il tracker di sicurezza della distribuzione. Aggiorni tramite il gestore di pacchetti, riavvii il servizio e ricontrolli. Tenga un elenco dei server SSH nel Suo inventario, così il prossimo bollettino richiederà minuti e non giorni.

No. È un indizio forte, non una prova, in entrambe le direzioni. Il banner è il testo che un server dichiara sul proprio software, come OpenSSH_8.9p1 Ubuntu-3ubuntu0.10. Le distribuzioni Linux spesso correggono le vulnerabilità applicando patch alla vecchia versione invece di passare alla nuova versione upstream, quindi un server può dichiarare una versione elencata come vulnerabile ed essere comunque sicuro; lo indicano il suffisso del pacchetto della distribuzione e il suo tracker di sicurezza. Il banner può anche essere modificato o nascosto da un amministratore, e alcune appliance dichiarano stringhe fuorvianti. Al contrario, un numero di versione aggiornato non esclude problemi di configurazione, come accessi con password aperti a internet o chiavi host deboli. Usi il banner per dividere i server tra quelli da verificare per primi e quelli probabilmente a posto, poi confermi sull'host con il gestore di pacchetti o con una scansione delle vulnerabilità autenticata. Non segnali mai alla direzione un server come compromesso o vulnerabile sulla base del solo banner.