Carissimi, "MELLIA MARCO" <marco.mellia@polito.it> writes:
Caro Alberto,
Chi ha scritto quanto sotto non capisce il problema e non sa di che cosa sta parlando.
Jeffrey Paul (pare) ha fatto un grave errore nel dire che tra le informazioni inviate c'è l'"Application hash", Jacopo Jannone - come prontamente segnalato da Alberto - lo ha corretto in https://blog.jacopo.io/en/: --8<---------------cut here---------------start------------->8--- * No, macOS does not send Apple a hash of your apps each time you run them. * You should be aware that macOS might transmit some opaque information about the developer certificate of the apps you run. This information is sent out in clear text on your network. --8<---------------cut here---------------end--------------->8--- Da questo ricavarne che Jeffrey Paul non conosce quello di cui parla è almeno ingeneroso, anche perché nel suo articolo Paul dice delle cose interessanti oltre alla (presunta) sciocchezza in merito all'invio dell'hash: quella è solo una *parte* della storia, non "buttiamo" il resto come spazzatura, neh :-) D'altronde sarei curioso di leggere un commento di Jeffrey Paul in merito a quento riscontrato da Jannone.
1) OCSP _deve_ essere in HTTP - essendo un protocollo per verificare scaricare i certificati pubblici delle certification authority. Non sarebbe possibile scaricare un certificato da verificare usando lo stesso certificato per cifrare la comunicazione (chicken and egg problem).
...a meno che in macOS ci sia, in locale e scaricato tramite aggiornamenti non OCSP, il certificato X.509 del server OCSP interrogato... ma mi pare che proprio il protocollo OCSP non preveda minimamente questo use-case; ma questo non è il punto.
2) Il download di Big Sur richiede (giustamente!) la certificazione del server da cui scaricare l’update - per ovvi motivi. Il carico eccessivo ha fatto crollare i server OCSP. E quindi impedire ulteriori richieste di download.
No, non è così: le richieste OCSP non vengono fatte solo per il download delle applicazioni ma anche ad ogni esecuzione di software: (https://blog.jacopo.io/en/post/apple-ocsp/) --8<---------------cut here---------------start------------->8--- [...] As Jeff Johnson explains in his tweet above, if macOS cannot reach Apple’s OCSP responder it skips the check and launches the app anyway - it is basically a fail-open behaviour. The problem is that Apple’s responder didn’t go down; it was reachable but became extremely slow, and this prevented the soft failure from triggering and giving up the check. It is clear that this mechanism requires macOS to contact Apple before an app is launched. The sudden public awareness of this fact, brought about by Apple’s issues, [...] --8<---------------cut here---------------end--------------->8--- Quindi in macOS *ogni* esecuzione di una applicazione genera una richiesta del demone trustd al server OCSP di Apple. Se il server OSCP è estremamente lento - per esempio sotto attacco DoS - il meccanismo di "fallback" (ignora la richiesta) non scatta e l'applicazonenon parte. Come minimo si può dire che non è una scelta sistemistica molto brillante, lato sistema operativo Solo per *accennare* alla questione della sicurezza dei binari distribuiti in un sistema operativo, faccio notare che altri - si prenda ad es. Debian - hanno adottato un approccio del tutto diverso (e non fanno richieste OCSP ad ogni esecuzione di software).
3) Quanto sopra non c’entra NULLA con la raccolta di informazioni statistiche e di debug relative ad applicazioni in uso - che certo non avviene tramite protocollo OCSP su HTTP.
Per qualsiasi scopo venga usato OCSP la cosa importante è sapere che _esistono_ problemi di privacy *e* di sicurezza legati al suo utilizzo, Alberto ha già risposto (<ef4e770f-d9b1-f74a-6dd6-46773e135229@zeromx.net>) in merito a questi aspetti. Io aggiungo "solo" che OCSP è semplicemente la risposta sbagliata a una serie di seri problemi di sicurezza dell'intero sistema X.509. Punto. :-)
Ipotizzo che il blocco del servizio OCSP abbia bloccato/reso malfunzionante anche questa raccolta dati in quanto il servizio non poteva usare cifratura per gli stessi motivi di cui sopra.
No: da quello che leggo (non conosco nessuno che ha macOS) l'estremo rallentamento del server centrale OCSP di Apple ha reso impossibile utilizzare le applicazioni installate sul proprio sistema.
4) Durante l’installazione del SO, e ad ogni aggiornamento dell'SO, apple chiede espressamente se vuoi partecipare alla raccolta dati, con una pagina chiara e dedicata. Questo sia per MacOS, iOS, iPadOS.
Ah se è per questo Apple ne dice tante, bisogna "solo" saperle interpretare... e fidarsi. [...]
5) Tale opzione si può cambiare in qualunque momento da pannello di controllo, con 3 semplici click (da pannello controll -> Sicurezza e Privacy -> Privacy -> Analisi e miglioramenti)
--8<---------------cut here---------------start------------->8--- Le informazioni che potrebbero consentire di identificarti non vengono salvate nei resoconti generati dal Mac e vengono trattate in conformità alle politica di tutela della privacy di tipo differenziale. [...] Tutte le informazioni di analisi vengono inviate ad Apple in forma anonima. --8<---------------cut here---------------end--------------->8--- Quindi: Apple sa *tutto*, si tratta "solo" di avere abbastanza metadati per incrociare i dati e sappiamo come si fa.
In sostanza - tanto rumore per nulla.
Proprio per nulla no, perché comunque quel giorno molti utenti macOS non sono riusciti ad aprire le loro applicazioni. Purtroppo Jeffrey Paul ha (probabilmente) commesso un grave errore nel denunciare che con le richeste OCSP vengono trasmessi in chiaro (http) anche gli hash delle applicazioni, *ma* - e sottolineo *ma* - certe agenzie dedite alla sorveglianza globale non hanno bisogno di intercettare il traffico in chiaro per sapere quali applicazioni sono installate su un dispositivo, considerato che quelle informazioni sono senza dubbio conservate da Apple [1] e oggetto di richieste FISA: https://www.apple.com/legal/transparency/ (sezione United States National Security, si apre solo via JS non c'è un puntatore diretto): --8<---------------cut here---------------start------------->8--- U.S. National Security requests seek customer data in response to national security related investigations. National Security requests include orders received under the Foreign Intelligence Surveillance Act (“FISA”) and National Security Letters (“NSLs”). To date, Apple has not received any orders for bulk data. Apple reports national security requests received for Apple users/accounts (NSLs and orders received under FISA) within bands permissible by law pursuant to the USA FREEDOM Act of 2015 (“USA Freedom”). Though we want to be more specific, these are currently the ranges and level of detail permitted under USA Freedom for reporting U.S. National Security requests. --8<---------------cut here---------------end--------------->8--- Comunque sì, direi che questa storia sposta solo di uno zerovirgola la questione fondamentale in merito a privacy *e* sicurezza dei sistemi proprietari posta da Alberto Berti (<87361aqfvg.fsf@metapensiero.it>): --8<---------------cut here---------------start------------->8--- Viene da chiedersi se chi compra prodotti Apple non abbia già espresso più o meno coscientemente la volontà di farsi "controllare", quindi se non sia un po' vano discutere di libertà dell'utente di una piattaforma così chiusa. --8<---------------cut here---------------end--------------->8--- D'altronde sono tanti gli episodi storici documentati, ormai: https://www.gnu.org/proprietary/malware-apple.html.en Ovviamente la cosa non è limitata ad Apple o macOS, non facciamone una questione di marca e modello :-D [...] Saluti, Giovanni -- Giovanni Biscuolo