_____
 / ____|
| |  __
| | |_ |
| |__| |
 \_____|
  ___
 / _ \
| (_) |
 \___/
 _ __
| '__|
| |
|_|
 _
| |
| |
| |
| |
|_|
  __ _ 
 / _` |
| (_| |
 \__,_|
 _ __  
| '_ \ 
| | | |
|_| |_|
 _ 
(_)
 _ 
| |
| |
|_|
      ___    ___    _ __ ___  
     / __|  / _ \  | '_ ` _ \ 
 _  | (__  | (_) | | | | | | |
(_)  \___|  \___/  |_| |_| |_|
Reverse, Repurpose, Resolve
Un uomo nel mezzo
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:
mitm
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.
mitm
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...
mitm
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.