Niente di nuovo qui, nessuna fantastica scoperta tecnologica pronta a rivoluzionare il
modo vivere. Anche fosse, ormai è tardi. Procediamo con ordine, inverso :-)
Sul mio device è piovuto Android KitKat 4.4, come sempre benvenuto in quanto "nuovo".
Però c’è un però. L’andazzo di Google sempre più invasivo non è una novità, quindi non
mi soffermo sulle cose spiacevoli che ho già riscontrato (chi ha detto Google Caller ID?).
Mi soffermo su un aspetto che mi ha fatto pensare più a fondo del solito su dove stiamo
andando a finire. Cominciamo la camminata all’indietro.
Dopo il primo boot il sistema mi presenta questo messaggio:
Avendo letto qualcosa pre-rilascio, il dubbio su cosa possa essere mi viene, ma soprassiedo.
Scorrendo i menu delle impostazioni però un triangolino arancio cattura la mia attenzione,
lo premo e ricompare quel messaggio.
Rileggendolo bene è piuttosto inquietante: qualcuno potrebbe intercettare i dati tra il mio
device e l’altro endpoint della comunicazione. Questo è sempre vero quando parliamo di internet,
ed è il motivo per cui esistono protocolli come TLS o <-L. Il messaggio però indica proprio
questo: le tue comunicazioni *cifrate* potrebbero essere intercettate comunque. E qui arriva
un altro passo indietro, per spiegare in poche parole come avviene una connessione cifrata tra
il nostro device ed un punto remoto, ad esempio un web server su cui vogliamo effettuare una
transazione. Si basa tutto sui certificati digitali, la bit-versione della carta di identità
che teniamo in tasca. Il "sito" cui ci colleghiamo ci fornisce un certificato digitale che non
comprende nulla di segreto, solo i dati che lo identificano tra cui il nome (cn, common name),
la data di validità e l’emittente. Esattamente come la nostra carta di identità che dice "Mario
Piccolo, nato il 6 agosto 1945". Perché ci fidiamo di questa carta? Perché c’è il terzo elemento,
l’emittente: "Emessa dal Comune di Pangasio Puppeni". Noi ci fidiamo del Comune di Pangasio Puppeni,
a sua volta diramazione dello stato centrale di cui ci fidiamo, l’Italia (ci sarebbe da aprire un’
altra discussione a riguardo, ma sarebbe fuori luogo…). Quindi la forza del certificato sta nella
fiducia che riponiamo in chi lo emette. Se una persona per identificarsi usasse la tessera del
club di pesca sportiva, la sua identificazione sarebbe meno incisiva e non molti (esclusi i soci)
la prenderebbero per buona.
Ora, tornando al nostro sito, vediamo che questo ci presenta un certificato digitale rilasciato
da una certa autorità: noi ci fidiamo di lei, quindi procediamo ad estrarre dal certificato una
chiave con la quale ne genereremo un’altra e la useremo per cifrare i dati tra noi ed il server.
Un po’ di matematica dice che si può fare, quindi siamo a posto. Se il certificato è buono, è
buona anche la chiave in esso contenuta e da qui partiamo con la cifratura. Altro passo indietro:
ho detto che ci fidiamo dell’autorità che ha emesso il certificato, ma chi l’ha detto? Qui sta
il fulcro del discorso. Il nostro browser, spesso assieme al sistema operativo, contiene una
lista di autorità emittenti "Trusted", ossia fidate, come fosse l’elenco di tutti i Comuni d’Italia.
Ogni certificato rilasciato da una di queste autorità per noi è sacro, purché abbia il nome
corretto scritto sopra e non sia scaduto (o revocato, ma oggi sorvoliamo).
Basandoci su questo possiamo spiegare in poche parole cos’è un attacco MITMFB®, Man In the Middle
Fatto Bene. Il "Fatto Bene" l’ho aggiunto io, a breve si capirà il perché.
La sicurezza "end to end" delle connessioni TLS/SSL sta nel fatto che solo il mio device e quello
destinatario conoscono la chiave che ci siamo scambiati ad inizio comunicazione, ottenuta lavorando
con la chiave presente nel certificato. Chiunque nella rete può sniffare (catturare) il mio traffico,
ma solo io ed il destinatario possiamo decifrare i contenuti.
Io <- Cifratura con chiave del certificato buono ->Server
Qui arriva l’uomo nel mezzo. Potendo accedere al mio medium di comunicazione (rete cablata, WiFi, 3G, …)
qualcuno può intercettare la mia richiesta iniziale di certificato al server, fermarla e fornirmi un
certificato finto invece di quello buono e farmi negoziare una chiave di cifratura. A questo punto la
comunicazione iniziale è spezzata in due: da me all’uomo nel mezzo, e dall’uomo nel mezzo al server
finale. Le due semi-comunicazioni sono ognuna cifrata, con l’uomo nel mezzo che decifra i dati tra me
e lui e li ri-cifra per fargli proseguire la comunicazione. Nel mezzo, l’uomo ha i dati in chiaro.
Io <- Cifratura con certificato farlocco ->Uomo nel mezzo <-Cifratura con certificato buono ->Server
Cosa può andare storto, per l’uomo nel mezzo? Il certificato che fornisce a me non è quello originale
del server (di cui non avrebbe la chiave per decifrare i dati) ma uno inventato al volo (assieme alla
chiave di decifratura). Il mio client deve perciò fidarsi di questo certificato "volante", perché mai
dovrebbe farlo? Perché costui emette certificati che il mio device considera sicuri, avendo l’emittente
farlocco tra quelli qualcuno ha listato come "attendibili". È come se nella mia lista "mentale" dei
Comuni d’Italia, attendibili per rilasciare carte d’identità, ci fosse anche l’associazione di pesca
sportiva di cui sopra; a quel punto mi fiderei di un documento emesso da "Gli amici della trota" esattamente
come della zecca di Stato.
Questo è il significato del messaggio di Android: attenzione, guarda che ai certificati che Google ha
deciso essere affidabili, ne è stato aggiunto un altro, e che questo permette di stampare certificati
farlocchi di cui ti fiderai ciecamente.
Se non fosse che il certificato aggiunto è mio, e lo uso per lavoro, mi verrebbe da ringraziare Google.
Ma se rileggo la mia stessa frase vedo dove sta la presa per il culo: "ai certificati che Google ha deciso
essere affidabili". Come potete vedere sul vostro device ce ne sono a decine di certificati "certamente
attendibili", dove la certezza dell’attendibilità la decide Google, almeno finché non interveniamo
manualmente disabilitandoli a mano uno per uno.
I certificati sani...
Il messaggio di Google dice "scusa sai, io decido chi e come può emettere certificati che consentono di
sniffare i tuoi dati: perché mai vorresti fare anche tu la stessa cosa? Guarda che magari qualcuno sta
facendo il furbo, stai attento!".
Beh, a me sta cosa fa girare le balle. Fatti pure gli affari miei, ma almeno non prendermi in giro (pure
per i certificati pinnati).
Esistono parecchie considerazioni da fare sulla sicurezza di una connessione cifrata e questo non vuole
certamente essere un articolo esaustivo. La vera sfortuna è che questo modello si applica alla stragrande
maggioranza delle connessioni di noi utenti "normali" (ed in qualche caso è addirittura normale che venga
implementato), quindi chi vede il messaggio su in apertura potrebbe prendersi male, ma tutti gli altri non
vedendolo se ne stanno tranquilli, sicuri che i certificati che Google ha messo in Android (o Apple in iOS,
o Microsoft in Windows, o …) sono roba buona.