Capitolo #4 - RC4, verso il tramonto?
Troppo bello per restare segreto, troppo utile per sparire subito
English version available here → [EN]
1987. Il mondo ragionava per blocchi, confini e recinti. L’esempio più eclatante: la guerra fredda tra USA e Unione Sovietica.
Berlino ne era il simbolo più evidente e il Muro era ancora in piedi a ricordarlo a tutti. Il 12 giugno di quell’anno il presidente USA di allora, Ronald Reagan, davanti alla Porta di Brandeburgo, pronunciava una frase destinata a restare nella storia come una provocazione e una speranza insieme:
“Mr. Gorbachev, tear down this wall!”
Pochi mesi dopo, l’8 dicembre, Stati Uniti e Unione Sovietica firmavano il trattato INF, primo segnale concreto di un equilibrio che iniziava lentamente a incrinarsi. Fuori c’erano ancora i muri, ma da qualche parte si iniziava già a parlare di futuro.
È in quella strana sospensione, tra muri ancora intatti e crepe già visibili, che nasceva un algoritmo di cifratura destinato a durare a lungo: RC4.
Non come standard aperto, non come bene comune, ma come segreto industriale. In quell’anno infatti Ron Rivest, uno dei fondatori di RSA Data Security, progetta l’algoritmo come componente della libreria crittografica proprietaria RSA.
La sigla viene comunemente tradotta in “Rivest Cipher 4”, anche se secondo Ron Rivest stesso le lettere RC stavano per “Ron’s Code”.
Quando penso a quel 1987, però, non riesco a sentirci solo la geopolitica o la tensione della Guerra Fredda. Ci sento anche altro.
Nei club la musica House vive la sua epoca d’oro, e il sottoscritto ne rimane ammaliato, muovendo i primi passi tra vinili, mixer e dei fidatissimi Technics SL-1210 MK2. La cosa curiosa è che, come l’RC4, anche la tecnologia musicale di allora era progettata per durare. Ancora oggi posso accendere lo stesso impianto e suonare gli stessi vinili senza alcun problema.
Ma parlando di vinili, se ne devo scegliere uno per fare da cornice al contesto storico, il primo che mi viene in mente è Promised Land di Joe Smooth. Perché mentre fuori il mondo era ancora fatto di separazioni, dentro quel suono girava già un’idea opposta:
“brothers and sisters, one day we will be free”
non più divisione, non più conflitto, ma l’idea che si possa finalmente camminare nella stessa direzione.
Poi arrivò il 9 novembre 1989, e il Muro di Berlino cadde davvero. Con lui non venne giù soltanto una barriera di cemento, ma l’idea stessa che certi recinti fossero naturali, inevitabili o destinati a durare per sempre. Da lì in avanti il cambiamento non fu solo politico. Fu culturale. Cambiò il modo di guardare ai confini, alla circolazione delle idee, alla pretesa che alcune cose dovessero restare chiuse in eterno, creando un effetto domino che si diffuse ovunque negli anni seguenti.
Cinque anni dopo, 1994, quel mondo non è ancora finito del tutto, ma ha già perso la sua rigidità originaria. E infatti, in un modo perfettamente anni Novanta, anche RC4 esce dal recinto con un leak dalla grande risonanza mediatica: una descrizione dell’algoritmo viene pubblicata anonimamente sulla mailing list dei cypherpunks e poi rilanciata su sci.crypt. Il segreto smette di essere tale e comincia la sua divulgazione.
Il caso finisce anche su TIME con un articolo dal nome “The Secret’s Out”. Segno che il leak non è più solo materia da addetti ai lavori.
Ma invece di decretarne la fine, quel leak ne inaugurò una seconda vita: da segreto industriale RC4 diventò oggetto di circolazione, implementazione e discussione sempre più ampia.
Passano altri cinque anni, 1999, anche Microsoft decide di adottare RC4 come algoritmo di cifratura standard per la propria implementazione Kerberos, usandolo come ponte di compatibilità per accompagnare la transizione dagli ambienti Windows NT esistenti e contribuendo a farlo diventare uno dei pilastri delle autenticazioni Windows per i decenni a venire.
La cosa curiosa è che nemmeno allora la storia si considera davvero completa, bisogna aspettare addirittura dicembre 2006 perché questa parte della sua vita venga formalizzata in un RFC (4757) che documenta i tipi di cifratura RC4-HMAC usati da Microsoft in Windows.
Più di dieci anni dopo la sua rivelazione pubblica, quasi vent’anni dopo la sua nascita. Come se la burocrazia, ancora una volta, si limitasse a registrare qualcosa che la pratica aveva già accettato da tempo.
E proprio qui, tra un segreto troppo bello per restare tale e un’idea troppo utile per sparire subito, comincia davvero la storia del suo declino.
Perché RC4 è arrivato davvero al tramonto
Prima di raccontare perché RC4 sia arrivato al tramonto, vale la pena ricordare perché abbia avuto così tanta fortuna. Non si è diffuso per caso, né soltanto perché era disponibile. Per il mondo degli anni Novanta era quasi perfetto: era veloce, semplice da implementare, leggero per l’hardware dell’epoca e abbastanza flessibile da infilarsi in contesti molto diversi tra loro. Non richiedeva strutture particolarmente complesse, lavorava bene in software e poteva essere adottato in protocolli che avevano bisogno di cifrare flussi di dati in modo pratico, senza appesantire troppo sistemi e applicazioni.
Per questo finì ovunque: nelle prime versioni di SSL e TLS, nelle reti Wi‑Fi con WEP, poi WPA/TKIP, e infine come già visto dentro Kerberos in ambiente Windows. In altre parole, RC4 non era solo un algoritmo: era una soluzione pratica a un problema molto concreto, quello di portare un po’ di cifratura in un mondo che stava diventando sempre più connesso, ma che non poteva ancora permettersi di cambiare tutto insieme.
Ma quindi, cosa ne sta decretando la fine?
RC4 non esce di scena perché qualcuno ha deciso, all’improvviso, che fosse soltanto “vecchio”. Esce di scena perché il mondo che lo aveva reso una buona idea è cambiato. Per anni è stato il compromesso perfetto: solido quanto bastava per sembrare moderno, flessibile quanto serviva per accompagnare sistemi che dovevano evolvere senza potersi permettere di buttare via tutto ciò che c’era prima.
Il punto è che i compromessi tecnici invecchiano male quando il contesto smette di proteggerli. Ed è esattamente quello che è successo a RC4. Con il tempo sono emerse debolezze crittografiche sempre più difficili da ignorare, mentre intorno crescevano attacchi più pratici, più accessibili e alternative più solide. Non è un caso se RC4 ha iniziato a uscire di scena in più ambiti: nel 2015 l’IETF ne vieta l’uso in TLS, nel 2020 ne depreca formalmente l’uso in SSH, e nel mondo Wi‑Fi il settore spinge da anni verso WPA2 con AES, lasciandosi alle spalle le soluzioni transitorie che ancora si appoggiavano allo stesso cipher di fondo.
Questo introduce il caso Microsoft, che non va letto come un’eccezione, ma come uno degli ultimi capitoli di una storia già iniziata altrove. Nel post ufficiale Beyond RC4 for Windows authentication, Microsoft dice apertamente che RC4 è suscettibile ad attacchi come il Kerberoasting e che un’autenticazione Windows sicura non ha più bisogno di lui, perché AES è disponibile da anni su tutte le versioni supportate. In altre parole, RC4 non smette di funzionare: arriva al tramonto quando il presente smette di avere buone ragioni per continuare a farne uso.
Come Microsoft sta accompagnando RC4 fuori scena
A guardarla bene, questa storia non comincia quest’anno. Microsoft aveva già iniziato a spostare il baricentro lontano da RC4 almeno dal 2022, quando gli aggiornamenti legati a CVE-2022-37966 hanno portato AES a diventare il default per le session keys sugli account senza impostazioni esplicite. Non era ancora una dismissione finale, ma il segnale era già chiaro: il vecchio compromesso stava perdendo terreno. Anche la documentazione più recente lo riconosce apertamente, spiegando che quel cambio ha già ridotto in modo significativo l’uso di RC4, pur senza eliminarlo del tutto.
Il 2025 e soprattutto il 2026, però, cambiano il tono della musica. Non siamo più nel campo dell’hardening progressivo o del dettaglio tecnico che passa quasi inosservato in una cumulative update. Siamo nel momento in cui Microsoft decide di rendere esplicita la traiettoria e di scandirla in fasi molto leggibili: prima l’audit, poi il cambio di comportamento di default, infine la chiusura della tolleranza implicita. È come se per anni ci fosse stato un cartello “lavori in corso” all’ingresso, e solo quest’anno qualcuno avesse cominciato davvero a chiudere la strada.
Il punto di svolta, a quel punto, diventa luglio 2026. Perché è lì che la timeline smette di essere una successione di avvisi e diventa scadenza vera. KB5073381 dice che gli aggiornamenti rilasciati in quel periodo abiliteranno programmaticamente la Enforcement Phase; la procedura operativa che stiamo usando sul campo lo traduce in maniera ancora più netta: niente rollback comodo, niente ritorno al passato per inerzia, niente fallback implicito lasciato lì a proteggere ciò che nessuno ha ancora messo in ordine. Da quel momento RC4 continua a vivere solo dove qualcuno lo avrà mantenuto in modo esplicito, account per account, eccezione per eccezione.
Ed è proprio qui che la faccenda si fa interessante. Perché Microsoft mette a disposizione strumenti ufficiali per affrontare il problema: più visibilità nei log, una pagina di guidance su come rilevare e correggere l’uso di RC4, e degli script PowerShell di auditing richiamati nella documentazione ufficiale. Ma la realtà è che questi strumenti, da soli, rischiano di restituire una fotografia piena di rumore.
La documentazione Microsoft stessa spiega che RC4 continua a comparire per ragioni diverse: sistemi legacy, account senza impostazioni esplicite, configurazioni incomplete. E l’esperienza sul campo aggiunge un dettaglio ancora più concreto: i grandi numeri grezzi possono essere fuorvianti, l’assenza di traffico RC4 rilevato non è sempre conclusiva, e certe categorie, come gli account “senza AES keys” letti in modo superficiale, rischiano di allargare il problema più di quanto serva davvero.
Per questo il passaggio successivo non può essere solo tecnico. Serve un approccio ampio, sì, ma soprattutto pragmatico: abbastanza esteso da non perdere i segnali deboli, abbastanza lucido da non farsi travolgere dal rumore di fondo.
Perché nei sistemi enterprise il passato non si presenta quasi mai in modo ordinato. Si annida nelle abitudini, nelle impostazioni ereditarie, nei default lasciati lì per anni, nei comportamenti che sembrano normali solo perché nessuno li guardava più da vicino.
Ed è da lì che bisogna partire, se davvero si vuole arrivare ai nodi chiave e iniziare a sbrogliare la matassa.
Cosa sta emergendo dalle analisi che stiamo facendo
Quando si passa dalla teoria ai sistemi veri, la faccenda smette subito di sembrare lineare. Sulla carta il problema potrebbe apparire quasi banale: Microsoft cambia un default, RC4 esce di scena e chi è rimasto indietro si adegua.
Mi è capitato più volte di sentire frasi del tipo: “sono abbastanza sicuro che da noi non avrà impatti”. E ogni volta mi sono chiesto da dove arrivasse tutta quella sicurezza.
Nella pratica, infatti, i sistemi enterprise non ragionano mai in modo così pulito. Ragionano per abitudini, per stratificazioni, per impostazioni ereditate che continuano a produrre effetti molto tempo dopo che ci si è dimenticati perfino il motivo per cui erano state messe lì. Ed è proprio in questa zona grigia che RC4 continua a lasciare tracce.
Guardando i dati emersi sul campo, la prima cosa che si capisce è che i numeri grezzi aiutano fino a un certo punto.
Partendo da uno sguardo d’insieme, il quadro tende quasi sempre a restringersi attorno agli stessi punti sensibili. Non tanto i grandi volumi indistinti, ma una manciata di account di servizio con SPN, password storiche mai ruotate, qualche sistema non Windows o non chiaramente AES-capable, e tutti quei pezzi d’infrastruttura che vivono tranquilli da anni proprio perché nessuno ha più avuto motivo di toccarli.
A contorno centinaia o migliaia di oggetti utente e computer che si sistemano con un approccio pragmatico, ma che nascondono alla vista i nodi focali.
Nei report che stiamo producendo la logica torna spesso la stessa: il lavoro vero non sta nei grandi numeri che fanno impressione in una tabella, ma in pochi oggetti che tengono ancora in piedi dipendenze pesanti e poco visibili.
C’è poi un altro aspetto, forse il più insidioso: l’assenza di evidenze forti non coincide automaticamente con l’assenza di problemi.
In più di un caso la raccolta eventi è risultata limitata o parziale, e la raccomandazione è quella di impostare una finestra di audit abbastanza ampia quando i dati non bastano a chiudere il quadro.
Anche qui torna il solito paradosso dei sistemi legacy: il passato non fa rumore quando è davvero presente, anzi spesso resta tranquillo finché qualcuno non decide di guardarlo meglio.
Per questo, più andiamo avanti, più il punto mi sembra chiaro: affrontare RC4 non significa semplicemente “cercare dove appare” e spegnerlo ovunque. Significa leggere i sistemi con una lente abbastanza larga da non perdere il contesto, ma abbastanza pragmatica da individuare i nodi che contano davvero.
Non serve inseguire ogni riflesso. Serve capire quali segnali portano a dipendenze reali, quali sono solo rumore di fondo e dove conviene intervenire senza farsi travolgere dal groviglio.
Ed è proprio qui che l’esperienza sul campo diventa vitale: perché nei sistemi legacy il problema raramente è dove lo vedi subito. Più spesso è dove nessuno pensava più di dover guardare.
Note pratiche dal campo
A questo punto vale la pena scendere ancora di un livello. Perché i dati aiutano, ma sono gli esempi concreti a far capire dove il passato continua davvero a pesare. In questo caso ho chiesto aiuto al collega Mattia Grandi, che ha riassunto bene gli aspetti più tecnici in questo articolo.
Parlando di casi emblematici il primo che mi viene in mente è Kemp Loadmaster, molto spesso usato per fare ripubblicazioni con Kerberos Constrained Delegation (KCD).
Questo è uno di quei casi in cui l’implementazione Kerberos non è “Windows native”. Di conseguenza il cambio di algoritmo va effettuato con cautela, identificando bene la sequenza operativa e una finestra manutentiva dedicata. È un pattern comune nelle implementazioni Kerberos di terze parti.
Guardando poi “verso il cielo” ci possiamo trovare a dover gestire lo storico account AZUREADSSOACC$, utilizzato per la funzionalità di Seamless Single Sign-On per Entra ID.
È un classico esempio di implementazione cloud-driven che, proprio perché nata con un default storico su RC4, oggi mostra tutti i limiti di quella scelta.
Bisogna poi ricordarsi che il Kerberos per sua natura non è confinato a un solo dominio, ma spesso esce dai confini attraverso le Trust.
Queste ultime sono altrettanto suscettibili rispetto all’algoritmo di funzionamento impostato: se ho una Trust che non supporta AES, o che non ha AES configurato, la chiusura del RC4 la “romperà” come se fosse un PC qualsiasi, ma con effetti molto più diffusi.
Parliamo infine di sistemi legacy, che siano dei Windows Server 2003 sopravvissuti ai decenni o implementazioni di terze parti che non supportano AES, ad esempio gli immortali sistemi AS/400.
In questi casi non sempre sarà possibile chiudere RC4 in modo netto e immediato.
Sarà invece necessario indagare in maniera puntuale quale sia l’utilizzo effettivo che viene fatto del Kerberos. Questo per poter gestire esclusioni mirate e consapevoli.
Come vedete, lo spettro d’azione si allarga in fretta. Il rischio non è solo rompere qualcosa, ma perdere il controllo della situazione o concentrare gli sforzi dove non serve davvero.
Cosa ci ha insegnato il tramonto di RC4
La prima lezione che il tramonto di RC4 ci lascia è semplice solo in apparenza: i compromessi tecnici più riusciti sono anche quelli più difficili da mandare in pensione. RC4 è sopravvissuto così a lungo non perché fosse perfetto, ma perché per anni è stato veloce, pratico, compatibile e sufficientemente leggero da diventare invisibile. E quando una tecnologia diventa invisibile, smette di essere discussa molto prima di smettere di produrre effetti reali.
La seconda lezione riguarda il modo in cui trattiamo il passato nei sistemi enterprise. Ignorarlo non lo rende innocuo. Lo rende solo più difficile da riconoscere quando torna a presentare il conto. Nel caso di RC4 quel conto ha anche una data abbastanza precisa: luglio 2026. Chi arriverà a quel punto ancora dipendente da questo vecchio compromesso non si troverà davanti a un mistero, ma a fallimenti di autenticazione ampiamente prevedibili.
Questo non significa affrontare il tema in modo ideologico. Nei sistemi reali esistono sempre eccezioni, dipendenze, appliance che non seguono i tempi del resto dell’infrastruttura, sistemi davvero non AES-capable e integrazioni che richiedono una transizione più lenta. Ma proprio perché queste eccezioni esistono, devono restare quello che sono: eccezioni vere, documentate, approvate e riesaminate. Non una nuova normalità dietro cui continuare a nascondere l’inerzia.
Perché compatibilità e inerzia non sono la stessa cosa. La compatibilità è una scelta progettuale consapevole: serve a far evolvere un sistema senza spezzarlo. L’inerzia, invece, è quello che rimane quando quella scelta smette di essere governata. È il default lasciato lì troppo a lungo, l’account di servizio mai rivisto, la trust che nessuno tocca più, il sistema legacy che continua a funzionare non perché sia stato compreso, ma perché nessuno ha ancora avuto il coraggio o il tempo di guardarci dentro.
In fondo è lo stesso filo che attraversa tutti questi capitoli. Il guardiano di AdminSDHolder, le trust nate per dare forma alla fiducia, il Domain Controller che sembrava mentire: ogni volta il punto non era che il sistema fosse rotto. Il punto era che il sistema continuava a fare quello per cui era stato progettato, mentre noi avevamo perso parte della memoria di quel progetto.
RC4 racconta la stessa cosa da un’altra angolazione. Non è il mostro da cancellare dalla storia, e nemmeno il simbolo di un errore clamoroso. È stato una buona risposta a un problema del suo tempo. Solo che il tempo, a un certo punto, cambia domanda. E quando cambia domanda, continuare a dare la stessa risposta non è più compatibilità: è ostinazione.
Forse è questa la lezione più importante del suo tramonto: non possiamo pretendere che i sistemi legacy spariscano da soli, né che smettano spontaneamente di influenzare il presente. Dobbiamo guardarli, capirli, decidere cosa salvare e cosa accompagnare fuori scena. Senza nostalgia, ma anche senza arroganza. Perché molte delle cose che oggi chiamiamo legacy sono state, nel loro momento, ottime soluzioni.
Il problema nasce quando continuiamo a trattarle come se il mondo intorno non fosse cambiato.
RC4 ha avuto una vita lunga, utile e per certi versi sorprendente. Adesso però il tramonto non è più una metafora: è una deadline. E, come spesso accade nelle infrastrutture enterprise, la differenza tra una transizione ordinata e un incidente evitabile sta tutta nel decidere se occuparsene quando c’è ancora luce, oppure aspettare il buio.