Premessa: posto lunghetto ed un pochino geek.
C’è stato un tempo in cui era possibile avere il completo controllo del proprio Personal Computer anche sui sistemi operativi “mainstream“.
Di questi tempi quello è sempre meno il caso. Da una parte Windows che decide in maniera autonoma quando installare gli aggiornamenti di sistema imbottendo il computer di software non richiesto.
Dall’altra parte Apple che con sottili cambiamenti al sistema operativo sottrae sempre più contro all’utente finale.
E’ proprio di Apple che voglio parlare in questo post.
Cominciamo dal passato recente. Durante il WWDC19 Apple ha annunciato che non sarà più possibile per gli sviluppatori scrivere Kernel Extensions. Questo è il documento ufficiale in cui viene fatto l’annuncio: Deprecated Kernel Extensions and System Extension Alternatives.
Il razionale che viene riportato è questo:
At WWDC19, we announced the deprecation of kernel extensions as part of our ongoing effort to modernize the platform, improve security and reliability, and enable more user-friendly distribution methods. Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default.
Deprecated Kernel Extensions and System Extension Alternatives
Quindi sembra che lo stiano facendo per modernizzare la piattaforma ed aumentarne sicurezza e affidabilità. Da un certo punto di vista ci posso anche credere. Una kernel extension non è certo una banalità dal momento che risiede nel cuore pulsante del sistema operativo. Dall’altro lato le cose più fighe in termini di sicurezza e di usabilità erano proprio fatte a livello di kernel extension. Parliamo ad esempio di una utility fighissima che era Audio Hijack e che permetteva di fare routing dell’audio nelle maniera più fantasiose ed utili possibile. C’era Little Snitch che permetteva di attivare, disattivare e monitorare le connessioni di rete verso sistemi esterni. Nei miei momenti più paranoici ho anche usato un paio di applicazioni, di cui non ricordo il nome, che monitoravano una l’uso di altre kernel extension ed un altra l’apertura di ogni singolo file a livello utente. Un pochino troppo, lo ammetto.
Nel prosieguo di questo post il tema Little Snitch ci tornerà utile.
L’altro ieri Apple rilascia Big Sur, il nuovo sistema operativo per Mac e pochi giorni dopo annuncia il rilascio dei computer con architettura ARM.
Gli utenti scaricano il sistema operativo e subito molti lamentano di non essere in grado di lanciare applicazioni non provenienti da Apple.
I responsabili del problema sono i sistemi che si occupano di implementare il protocollo OCSP, Online Certificate Status Protocol.
Vediamo di che si tratta.
Chiunque si è trovato a dovere pubblicare su App Store una applicazione per i sistemi Apple, siano questi iPhone, Mac, Apple TV, Apple Watch sa benissimo che queste applicazioni devono essere firmate digitalmente con il certificato dello sviluppatore. (Sto semplificando, ma va bene così). Ogni volta che una applicazione viene lanciata il sistema si collega ad uno dei sistemi di Apple, tipicamente ocsp.apple.com e verifica la validità del certificato. Se il certificato è valido l’applicazione viene lanciata, se il certificato è valido questa viene bloccata. Tutto questo, almeno sui Mac, avviene utilizzando un processo che vive in background e che si chiama trustd.
Tutto questo è descritto in questo documento: X.509 Internet Public Key Infrastructure – Online Certificate Status Protocol – OCSP
Per qualche ragione a noi sconosciuta i server in questione hanno avuto dei problemi e hanno rallentato, e spesso bloccato, il processo di verifica di questi certificati. Gli utenti si sono trovati quindi impossibilitati ad utilizzare alcune applicazioni sul nuovo sistema operativo.
Ottimo. L’idea non è affatto male e sembra fatta apposta per proteggere la nostra sicurezza di utenti finali.
Diciamo quasi perché ci sono diversi punti che vanno sottolineati:
- La richiesta di verifica avviene su protocollo HTTP e quindi avviene in chiaro. Questo significa che le richiesta sono perfettamente intelligibili da chiunque sia in grado di intercettare il traffico che viene generato. Facile.
- Essendo una richiesta GET su HTTP è molto facile capire da quale luogo è stata effettuata una richiesta. Sui log dei sistemi che ricevono la richiesta sarà quindi presente l’indirizzo IP dal quale viene generata la richiesta, il giorno e l’ora in cui la richiesta è avvenuta, e dei dati che identificano il certificato di cui viene effettuata la richiesta di verifica per ogni singola applicazione. In altre parole: da qualche parte c’è scritto che applicazioni uso, quando le uso e dove le uso.
Bene. A questo punto direte che sarà sufficiente passare da una VPN per evitare che si venga tracciati.
Beh, quasi… perché Apple si ha introdotto un’altra casetta interessante.
Se andate a vedere il file:
/System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist
scoprirete che esso contiene una lista di programmi. Tra questi programmi troverete anche il programma trustd di cui abbiamo parlato prima.
Sì, ma a cosa serve questo file? La risposta è inquietante. I programmi contenuti in questa lista eludono qualsiasi VPN installata sul sistema ed attiva così come eludono qualsiasi programma che permette di bloccare connessioni non desiderate (come ad esempio Little Snitch).
Quindi non c’è storia. L’informazione di cui sopra arriva ad Apple chiara e pulita nonostante tutto quello che noi utenti si possa fare per impedirla. Non potendo più scrivere Kernel Extension non c’è alcuno modo per farlo.
A livello di sistema operativo l’unico modo di bloccare queste richieste è avere a disposizione qualcosa a livello del kernel e che comunque deve sorpassare l’architettura che Apple ha deciso di implementare. Scrivere kernel extension non è più possibile ed anche se fosse possibile dubito che Apple approverebbe una applicazione siffatta.
L’altra opzione che si avrebbe a disposizione sarebbe quella di avere un firewall a valle del nostro router per la connessione ad Internet. A parte il fatto che non è una soluzione alla portata di tutti rimane il fatto che quando sono a spasso questa soluzione non è percorribile.
A questo punto se voglio essere sicuro, ammesso che sia possibile essere sicuri, devo rimanere su una versione del sistema operativo che non implementi le meraviglie di cui abbiamo parlato sopra.
Potrebbe essere una scelta. Ricordiamo che ora Apple ha presentato una nuova architettura hardware e che questa architettura supporta solo ed esclusivamente l’ultima versione del sistema operativo di Apple. Non posso quindi fare un downgrade ad una versione che mi possa proteggere.
Ancora una volta non si scappa.
Rimane, infine, da considerare un tema importante che riguarda l’utilizzo del sistema di verifica con OCSP. Tutti gli sviluppatori consegnano in questo modo ad Apple la possibilità di rendere inutilizzabili le loro applicazioni in qualsiasi momento e per qualsiasi ragione. Se pensassimo a scenari apocalittici potremmo anche pensare che un governo possa chiedere ad Apple di disabilitare una certa applicazione. Inverosimile ma possibile.
Ieri era sabato e quindi, con un pochino di tempo a disposizione, ho fatto qualche esperimento. Ho collezionato del traffico con Wireshark e ho effettivamente verificato che esiste un colloquio con Apple, ed in particolare con ocsp.apple.com e che questo traffico è in chiaro su HTTP. Quello che ho notato è che in realtà la verifica non viene fatta ad ogni singolo lancio della applicazione ma sporadicamente. Questo significa che il risultato della verifica viene messo in una cache e sino a che questa non scade non viene effettuata una nuova richiesta. Questo rende la granularità della collezione delle informazioni meno fine ma rimane il fatto che la richiesta viene fatta dall’indirizzo IP del mio provider. Dopo avere lasciato passare una giornata pochi minuti fa ho rifatto la prova ed ho bloccato le richieste di trustd attraverso Little Snitch. Beh, trustd se ne frega bellamente e continua a fare il suo lavoro ed il traffico passa senza alcuna limitazione.
Sinceramente non capisco perché la verifica del certificato debba essere fatta ad intervalli regolari. Il razionale mi sfugge. Io penso che la verifica sia sana una volta scaricata l’applicazione. Ma, fatta la verifica dopo l’installazione, e magari proprio contestualmente alla installazione, che motivo c’è di farla periodicamente?
Personalmente non credo che ci sia una precisa volontà da parte di Apple di ficcare il naso nei nostri affari ma la sensazione è proprio quella.
Una volta decidevo io con chi il mio PC poteva parlare e con chi no. Ora non ò più possibile. Beh, no, non è vero che non è più possibile ma è uno sbatti da niente.
Io credo che noi utenti dovremmo essere proprietari di ogni singolo dettaglio della macchina che usiamo. Certo, magari nessuno andrà mai a smanacciare nel kernel del sistema operativo ma io devo e voglio avere la possibilità di farlo.
Non penso che il razionale di Apple sia sensato.
Che palle.