Se vi siete imbattuti in questo articolo è probabile che abbiate da poco ricevuto una comuncazione da parte di Aruba volta ad avvisarvi che, a partire dal 30 settembre 2019, il servizio di Posta Elettronica Certificata (PEC) subirà degli importanti cambiamenti a livello di configurazione al fine di adeguarsi alle nuove richieste effettuate dall'Agenzia per l’Italia Digitale (AgID).
La comunicazione è la seguente:
Gentile utente,
nel rispetto di quanto richiesto dall’Agenzia per l’Italia Digitale (AgID) ai Gestori PEC (prot. N. 0004723 del 02/04/2019 e prot. N. 0008952 del 27/06/2019), ti comunichiamo che abbiamo recentemente attivato sul servizio di posta elettronica certificata il nuovo protocollo di trasmissione sicura “TLS 1.2” e che dal 30/09/2019 dismetteremo in modo definitivo gli altri protocolli, ormai obsoleti.
[...]
Il messaggio prosegue poi con una serie di informazioni dettagliate sulla compatibilità dei sistemi operativi e dei client di posta più diffusi con il nuovo protocollo. Nonostante la comunicazione sia piuttosto esaustiva, molti utenti - soprattutto quelli meno esperti di sicurezza informatica - si stanno chiedendo cosa bisogna effettivamente fare - o controllare - per assicurarsi che il proprio sistema continui a ricevere le PEC anche successivamente al 30/09/2019. Lo scopo di questo articolo è proprio quello di chiarire questo aspetto.
Cosa fare
Per i più frettolosi, la risposta è presto detta: non dovete fare assolutamente nulla, se non assicurarvi che il sistema operativo e il client di posta dei dispositivi che utilizzate per inviare e ricevere le PEC (e relative versioni) siano presenti tra quelli elencati nella comunicazione di Aruba, ovvero:
Sistemi Operativi e browser
- Android (4.4.2) | Tutti i browser
- Apple iOS | Tutti i browser
- Windows Phone (8.1) | Internet Explorer (11)
- OSX (10.9) | Safari (7.x), Chrome (34.x), Firefox (29.x)
- Windows XP (SP3) | Chrome (49.x), Firefox (49.x)
- Windows 7 | Chrome (30.x), Firefox (31.3.0 ESR/45.x), Internet Explorer (11), Opera (17.x)
- Windows 8.0 | Firefox (27)
- Windows 8.1 | Internet Explorer (11)
- Windows 10 | Tutti i browser
Client di posta e piattaforma
- Mail | iOS (11.x)
- Mail | Android (5.x)
- Apple Mail | OSX (10.12 Sierra)
- Outlook (2003) | Tutti i sistemi operativi
- Outlook 2011 (2011) | MAC OSX (Solo sulle versioni 10.11 - 10.13)
- Thunderbird (45.6) | Tutti i sistemi operativi
Come si può vedere, si tratta - fortunatamente - di sistemi e software già presenti e disponibili sul mercato da molti anni e che probabilmente già utilizzate. Nell'improbabile caso in cui non sia così, dovrete necessariamente pianificare un aggiornamento del vostro dispositivo e/o della vostra infrastruttura IT.
Per quanto riguarda le aziende e gli sviluppatori che hanno sviluppato delle integrazioni software con i servizi PEC, Aruba consiglia l'adozione dei seguenti framework sicuri:
- Java (8b132)
- Open SSL (1.0.1h)
- .NET Framework (4.6)
Tutte le informazioni contenute nella e-mail, insieme ad altri approfondimenti relativi al protocollo TLS 1.2 e ai singoli sistemi operativi e/o clienti di posta, sono disponibili nella apposita guida online messa a disposizione di Aruba sul proprio sito ufficiale.
Se capire cosa è necessario controllare entro il 30 settembre era l'unica cosa che vi interessava, potete fermarvi qui; se invece avete interesse ad approfondire le motivazioni di questo avviso, vi consigliamo di continuare a leggere. Come sempre accade quando si parla di sicurezza informatica, il modo migliore per affrontare queste problematiche non è quello di limitarsi ad eseguire passivamente le raccomazioni degli esperti, bensì quello di comprendere almeno a grandi linee il contesto di riferimento, così da aumentare il proprio livello di consapevolezza su temi che, anno dopo anno, stanno diventando sempre più importanti e delicati.
Nella seconda parte di questo articolo, dedicata a chi sceglie questo tipo di approccio, cercheremo di far luce sul funzionamento delle trasmissioni tra client e server di posta e sull'importante ruolo svolto da AgID e da altre organizzazioni che si occupano di definire gli standard di sicurezza informatica in Italia e nel mondo per regolarmentarne le dinamiche.
Agenzia per l'Italia Digitale
Per chi non lo sapesse, l'Agenzia per l'Italia Digitale è l'agenzia tecnica della Presidenza del Consiglio che ha il compito di garantire la realizzazione degli obiettivi dell'agenda digitale italiana e contribuire alla diffusione dell'utilizzo delle tecnologie dell'informazione e della comunicazione, favorendo l'innovazione e la crescita economica. Tra i principali compiti dell'AgID c'è, ovviamente, la definizione dei protocolli e delle misure minime di sicurezza ICT per le pubbliche amministrazioni, nonché per tutti i provider di servizi aventi valore legale: è il caso dunque anche dei provider autorizzati a mettere a disposizione dei propri utenti caselle di Posta Elettronica Certificata, le cui proprietà di sicurezza e certificazione sono state disciplinate nel D.P.R. n. 68 dell’11 febbraio 2005 e nei documenti tecnici collegati, dove sono elencate le regole tecniche per la corretta formazione e trasmissione della stessa e ulteriormente ribaditi, in tempi recenti, dalle Sezioni Unite della Suprema Corte (decisione n. 23620 del 28 settembre 2018).
Nel caso specifico, ad Aruba - così come tutti gli altri provider di servizi PEC - è stato chiesto di adeguarsi alle nuove richieste effettuate dall'AgID nel 2019 (prot. N. 0004723 del 02/04/2019 e prot. N. 0008952 del 27/06/2019) per incrementare i livelli di sicurezza delle trasmissioni di messaggi di Posta Elettronica Certificata. Le richieste, dal punto di vista della configurazione del servizio, si riassumono in due punti fondamentali:
- Adozione del protocollo di sicurezza Transport Layer Security (TLS) versione 1.2 (o superiore, se supportato dal client) per tutte le connessioni.
- Dismissione dei protocolli di sicurezza TLS 1.0, TLS 1.1 e SSL 3.0, che non dovranno più essere accettati o supportati.
Perché è importante adeguarsi
Le motivazioni alla base di tale richiesta sono tanto semplici da comprendere quanto necessarie: i protocolli di cui è stata richiesta la dismissione sono infatti stati classificati come non più sicuri e dunque obsoleti già da molti anni a seguito della scoperta di una serie di importanti vulnerabilità, tra cui:
- BEAST (acronimo di "Browser Exploit Against SSL/TLS"), un attacco basato su una vulnerabilità dell'algoritmo di cifratura (CBC) utilizzato da TLS 1.0 (settembre 2011).
- Heartbleed, un bug di sicurezza nella libreria di crittografia OpenSSL (dalla versione 1.0.1 alla 1.0.1f inclusa), utilizzata in molte implementazioni del protocollo TLS (aprile 2014)
- POODLE (acronimo di "Padding Oracle On Downgraded Legacy Encryption"), un attacco di tipo man-in-the-middle basato su una vulnerabilità del protocollo SSL 3.0 (CVE-2014-3566) e di dominio pubblico nell'ottobre 2014.
Come si può vedere si tratta di vulnerabilità tutt'altro che recenti, che in alcuni casi (Heartbleed e POODLE) ebbero anche una discreta copertura mediatica: la richiesta di AgID è dunque perfettamente ragionevole e, anzi, arriva a nostro avviso con oltre un anno di ritardo, in quanto agisce su protocolli che l'IETF (Internet Engineering Task Force, l'organizzazione internazionale che si occupa di sviluppare e promuovere standard per la rete Internet) ha dichiarato obsoleti in quanto non più sicuri nel 12 giugno 2018. Se consideriamo che IETF raccomanda l'utilizzo della versione successiva - il TLS 1.2 - a partire dall'agosto 2008, data di pubblicazione delle specifiche (RFC 5246), e che ha pubblicato le specifiche della versione ancora successiva (TLS 1.3) esattamente un anno fa (RFC 8446, agosto 2018), si può facilmente capire come si tratti di un aggiornamento assolutamente necessario.
Come funziona la trasmissione
Per capire bene in cosa consistono le modifiche richieste da AgID è necessario comprendere, almeno a grandi linee, come funziona il meccanismo di connessione sicura tra i due sistemi coinvolti nella trasmissione delle e-mail: il client, ovvero il software di posta installato sullo smartphone o sul PC dell'utente, e il server, ovvero la macchina che si occupa di ricevere i messaggi scritti dal'utente ad altri indirizzi di posta (e del loro invio ad altri server) e di inviare all'utente i messaggi a lui indirizzati.
Nel momento in cui il client si connette al server, i due sistemi cominciano a negoziare i dettagli relativi al protocollo di sicurezza da utilizzare e alle specifiche di cifratura, al fine di trovare il migliore accordo possibile: questa procedura, nota come handshaking ("stretta di mano"), ha il preciso compito di individuare il protocollo più sicuro tra quelli supportati da entrambe le parti, così da garantire il livello di sicurezza più alto tra quelli possibili. Ovviamente, poiché i protocolli vengono aggiunti, perfezionati e/o resi obsoleti nel corso del tempo, la quantità e la qualità dei protocolli di sicurezza supportati dipende soprattutto dal livello di aggiornamento del software - ovvero del sistema operativo e del client di posta - utilizzato dai dispositivi protagonisti della connessione: nella maggior parte dei casi i sistemi più recenti garantiscono il supporto di protocolli più moderni, sicuri, ed aggiornati, che potrebbero però essere indisponibili su macchine più vecchie.
Ad esempio, tutti gli smartphone recenti - dotati dell'ultima versione di Android o iOS - non soltanto supportano da tempo il TLS 1.2 e 1.3, ma hanno già rimosso tutte le versioni obsolete dalla lista dei protocolli disponibili per la negoziazione, nonché implementato disposizioni minime di sicurezza in base alle quali non consentono più l'installazione e/o l'utilizzo di client di posta che non supportino unicamente le versioni ad oggi considerate "sicure". Al tempo stesso, tanto un computer desktop con Windows 2000 quanto un vecchio smartphone con Android 3.x si troveranno nella situazione opposta: la loro lista di protocolli sarà con tutta probabilità quasi interamente composta da alternative ormai obsolete e non più sicure, con poche (o persino nessuna) possibilità di adeguarsi ai nuovi standard di sicurezza minimi.
La medesima situazione vale ovviamente anche per i server, per i quali vale però un discorso leggermente diverso: a differenza di quanto accade per i client, il cui compito è quello di negoziare la connessione unicamente con il server del fornitore di servizi, quest'ultimo ha la necessità di supportare il maggior numero possibile di client così da poter soddisfare il maggior numero possibile di utenti, compresi quelli che - per ragioni economiche, o legate alla pigriza, o per qualsiasi altro motivo - decidono di continuare a utilizzare sistemi obsoleti e dunque non più sicuri. Per questo motivo i provider di servizi internet hanno la tendenza a mantenere una lista dei protocolli di sicurezza disponibili per la negoziazione molto ampia, che include generalmente tutte le alternative più moderne e sicure ma anche quelle più obsolete e, di fatto, vulnerabili.
Una scelta spesso dettata da implicazioni economiche o di affidabilità nei confronti del cliente: impedire la connessione a sistemi obsoleti potrebbe infatti significare, per un provider, l'impossibilità di garantire il servizio a persone anziane o strutture per le quali un aggiornamento dei sistemi potrebbe essere oltermodo oneroso; è il caso di tante piccole aziende e/o realtà pubbliche (ad es. scuole, istituti di ricerca, etc.) ancora contraddistinte da un basso livello di informatizzazione che ancora esistono in Italia, che spesso non sono dotate di un responsabile IT interno e/o affidano la propria infrastruttura a fornitori esterni non sufficientemente proattivi.
E' proprio in quest'ottica che va intesa la richiesta di AgID ai provider: non tanto nell'obbligo di adozione del protocollo TLS 1.2, di fatto già implementato e supportato da Aruba e da qualsiasi altro provider, ma soprattutto nella necessità di impedire la negoziazione dei protocolli precedenti in quanto non più sicuri. Si tratta dunque di una restrizione aggiuntiva che il server dovrà obbligatoriamente imporre ai client, con l'evidente scopo di costringere quelli non più sufficientemente aggiornati - e quindi non più sicuri - a prendere i necessari provvedimenti per risolvere un problema che, se non affrontato immediatamente, potrebbe comportare il furto di dati propri e altrui.
Conclusioni
Per il momento è tutto: ci auguriamo che questo approfondimento possa essere d'aiuto tanto agli utenti quanto agli sviluppatori, amministratori di sistema, professionisti e appassionati di IT security che sono frequentemente chiamati ad affrontare questo tipo di sfide.
