Les utilisateurs de macOS Big Sur pistés par Apple ? Ce n’est pas aussi simple…

Ces derniers jours, Apple a fait face à une tempête qui s’est rapidement levée dans le sillage de l’arrivée de Big Sur. Des applications ne se lançaient plus et, pire, la société était accusée d’enregistrer leur fréquence d’utilisation et l’IP des utilisateurs. Entre bourdes et « conspirations », la société a clarifié la situation.

L’arrivée du dernier macOS n’a pas été de tout repos. D’une part, le système est arrivé plus tard que les années précédentes. Apple n'a communiqué la date finale que durant l’évènement de la semaine dernière (notre compte rendu), consacré à sa puce M1 et aux trois modèles de Mac l’embarquant (et qui sont disponibles dès aujourd’hui).

Le lancement très chaotique de Big Sur

D’autre part, la disponibilité du système a rapidement saturé les serveurs de l’entreprise. Même si Big Sur n’est pas encore envoyé automatiquement aux Mac compatibles (tous les modèles commercialisés à partir de 2013), l’attente générée – Apple ne remanie pas intégralement son interface tous les quatre matins – a provoqué un raz-de-marée de demandes sur le Mac App Store, qui distribue depuis des années les nouvelles versions de macOS.

Résultat, les taux de transferts se sont rapidement effondrés, aboutissant soit à de très longs temps de récupération (le système pèse pas moins de 12 Go), soit à un plantage de la procédure. Étonnant, Apple a lancé au cours de la même soirée la première bêta d’iOS 14.3, avant de se rendre compte que c’était une très mauvaise idée. La préversion a été retirée des serveurs moins d’une heure après.

Seulement voilà, la saturation des serveurs n’a pas uniquement concerné le téléchargement du système. De nombreux utilisateurs, après installation de Big Sur, ont été surpris de constater que leurs applications pouvaient ne plus se lancer. Pire, la société était accusée d’épier ses utilisateurs.

Gatekeeper et la notarisation au cœur de toutes les attentions

Avant d’évoquer en détail ce problème, revenons sur ce qu’est un service de notarisation. Mécanisme non spécifique à la société, il permet « la vérification et l'archivage des preuves d'échanges et d'archivage électroniques par un tiers de confiance agréé », pour reprendre la description donnée par Wikipedia.

Ce tiers de confiance agit littéralement comme un notaire. À une différence près : si en France l’activité notariée est régie par le droit et est donc strictement encadrée, on parle ici d’une structure numérique privée, ce qui implique une confiance a posteriori. Il s’agit certes d’une question de réputation, mais aussi – et avant tout – de vérification. La confiance se mérite et, dans le cas d’Apple, un martèlement marketing sur le respect de la vie privée ne suffit pas.

Le notarisation a été mise en place par Apple en 2018 pour compléter Gatekeeper. Dans les grandes lignes, elle permet de prouver qu’une application est bien ce qu’elle prétend être et d’en garder une trace. Le service fonctionne selon un système asymétrique classique : une clé privée pour le développeur et une clé publique pour l’utilisateur. Quand l’application démarre (un point capital sur lequel nous reviendrons), la clé publique est utilisée pour en vérifier l’authenticité.

Le certificat est dans tous les cas obligatoire pour distribuer une application sur le Mac App Store, mais le réglage par défaut de macOS depuis plusieurs années aboutit de toute façon au même résultat si l’application vient de l’extérieur : si le certificat est absent ou révoqué, l’application ne peut plus s’exécuter. Réglage que l’on peut changer dans les paramètres de sécurité du système, qui se fera une joie de vous alerter sur les dangers d’un tel mode.

Données personnelles et HTTP ne font pas bon ménage

OCSP (Online Certificate Status Protocol) est le protocole servant chez Apple à contrôler l’intégrité des applications, plus précisément de leur certificat X.509. La firme n’a rien inventé, le protocole existant depuis longtemps. Il est standardisé par l’IETF dans la RFC 6960 et a été créé pour résoudre certains problèmes inhérents aux listes de révocation des certificats. Notamment, le client n’a plus à récupérer de liste : il communique uniquement avec le serveur OCSP, qui lui répond alors que le certificat est valide ou non.

D’où est née la tempête ? D’un billet de blog du chercheur en sécurité Jeffrey Paul, daté du 12 novembre. Intitulé « Votre ordinateur n’est plus le vôtre », il décrivait comment Apple transformait petit à petit les Mac en nouvelles variantes de l’iPhone, augmentant son contrôle via des mécanismes comme Gatekeeper.

Plus précisément, Gatekeeper et OCSP permettraient à l’entreprise de savoir qui lance quoi, quand et à quelle fréquence. Apple tiendrait en effet un journal contenant les adresses IP des utilisateurs, l’empreinte des applications, celle du certificat, ainsi que l’heure et la date de la demande. De quoi bâtir un vaste tableau des habitudes des utilisateurs ? Inquiétant, d’autant plus que la communication vers les serveurs de la société se fait en HTTP, donc sans aucune sécurité.

L’article a fait sensation. En trois jours, la question était devenue prégnante : Apple épie-t-elle les habitudes de ses usagers ? On trouvait cette thématique notamment chez Framasoft et Tristan Nitot, qui évoquaient un avenir sombre pour l’informatique d’Apple, préfigurant ce que seraient les Mac de demain. Tristant Nitot a depuis nuancé son propos, pas Framasoft. Après tout, Big Sur est en cours de déploiement sur les Mac des sept dernières années et sera livré avec les premiers Mac M1, dont les livraisons ont commencé.

La vérité est plus nuancée.

Que s’est-il passé ?

Ce qui a attiré l’attention en premier lieu, c’est le plantage de l’infrastructure d’Apple gérant ces requêtes de vérification. Au moment même où Big Sur était lancé sur le Mac App Store, une erreur de configuration (a priori) laissait les applications en plan.

Pourquoi ? Parce que si Apple a prévu un mécanisme permettant aux applications de se lancer quand il n’y a pas de connexion internet (encore heureux), rien n’a été prévu pour le cas où il y a connexion, mais un problème avec les serveurs eux-mêmes. Les requêtes envoyées ne recevaient pas de réponse, et les applications, après avoir bondi pendant un temps dans le Dock, finissaient par signaler qu’elles avaient rencontré une erreur.

Une application notariée par Apple à son premier lancement

Tout était rentré dans l’ordre en moins d’une heure, mais ce laps de temps a été suffisant pour que beaucoup se posent des questions, à juste titre.

L’article de Jeffrey Paul n’a pas non plus tardé à être confronté à d’autres informations, notamment celles soulevées par un autre chercheur, Jacopo Jannone. Selon sa propre analyse, commandes et captures d’écran à l’appui, il brosse un portrait autrement plus nuancé.

Deux découvertes principalement. D’une part, l’empreinte de l’application n’est pas envoyée à chacun de ses démarrages. C’est bien le hash du certificat du développeur qui est transmis pour comparaison avec les informations que possède Apple sur l’application.

D’autre part, et c’est le plus important, cette empreinte ne peut pas identifier une application à coup sûr. Pourquoi ? Parce qu’un même certificat peut être utilisé pour plusieurs logiciels. Jannone a fait le test avec Firefox et Thunderbird : Mozilla utilise bien le même certificat pour les deux.

Il confirme en revanche que certaines informations sont bien envoyées : l’adresse IP, ainsi que l’heure et la date de la demande. Mais contrairement à ce qu’affirme Jeffrey Paul, Apple n’est pas en mesure de savoir quelle personne spécifiquement a lancé une application, du moins si l'on se base sur la seule analyse des requêtes. Si par exemple vous vous trouvez chez un ami et que vous lancez une application, l’adresse IP sera celle de son domicile et aucune de ces informations ne permettra de vous identifier.

Si l’on en croit l’analyse de Jannone, les requêtes ne contiennent aucune information permettant d’identifier à coup sûr une machine ou un utilisateur, comme une adresse Mac ou le compte Apple.

Cela étant, il y a quand même plusieurs problèmes.

Apple réagit et promet des améliorations

La communication de l’entreprise étant largement axée sur la sécurité et le respect de la vie privée, elle ne pouvait pas se permettre de rester silencieuse.

Apple a confirmé que l’adresse IP était bien collectée durant les échanges de données. Le mécanisme a donc été modifié en conséquence. L'entreprise promet que l’adresse n’est plus enregistrée et que toutes celles déjà présentes dans les journaux de connexion vont être supprimées.

En outre, plusieurs éléments vont être améliorés dans l’année qui vient. Premièrement, une version chiffrée du protocole sera mise en place afin de protéger les échanges. Car si OCSP n’impose pas le chiffrement des communications, on aurait apprécié qu’Apple soit proactive dans ce domaine. Deuxièmement, des « protections fortes » seront mises en place pour empêcher le plantage des serveurs. Gatekeeper a pris en effet des airs de SPOF (single point of failure, ou point unique de défaillance).

Enfin, et surtout, un paramètre sera intégré dans les Réglages de macOS afin de pouvoir couper ces mécanismes de protection. Toutes ces annonces sont présentes dans une version modifiée de la fiche technique liée à Gatekeeper, dans la section « Privacy protections » en bas de page. La version française n’a pas encore été mise à jour.

Dans l’ensemble, la situation reste problématique, car il est possible de savoir par exemple qu’à une heure donnée, Tor Browser a été lancé depuis une adresse IP spécifique, même si celle-ci est ensuite effacée. Le fait que ces informations circulent en clair rend la pratique bien peu vertueuse. D’autant que sans le plantage des serveurs OCSP, le loup n’aurait peut-être pas été soulevé avant un bon moment.

De plus, les promesses d’Apple seront à vérifier. Difficile en l’état de confirmer que les adresses IP ont bien été effacées, puisque personne en-dehors de l’entreprise ne peut contrôler ses journaux. Il sera cependant possible de contrôler si d’ici un an les communications passent bien par HTTPS et si le contrôle annoncé est bien implémenté dans macOS, et de quelle manière. Il faudra alors jauger ce qu’une telle désactivation coûtera potentiellement en matière de sécurité.

En clair, tout cela ressemble davantage à une bourde d’Apple qu’à un réel complot visant à surveiller les utilisateurs. La firme n’en ressort pour autant pas grandie : données identifiantes collectées et journalisées, serveurs qui flanchent, connexions non chiffrées… Une chose est sûre : le lancement de Big Sur aura marqué.

La primauté du choix

En filigrane derrière ces incidents, on trouve une problématique loin d’être nouvelle : le positionnement du curseur entre sécurité et liberté.

Le chemin choisi par Apple consiste à baliser le chemin pour le quidam. Aujourd’hui, une application ne peut plus se lancer si elle n’a pas au minimum un certificat authentique et valide intégré par le développeur. Le service de notarisation ajoute une couche supplémentaire, en pouvant pointer si le code a été modifié, ce qui peut indiquer la présence d’un malware.

Aucune de ces protections n’est parfaite, pas plus que celles pouvant protéger d’autres sources d’applications, quel que soit le système d’exploitation. Les logiciels seraient-ils plus sûrs si chacun les compilait soi-même ? Pas nécessairement.

Le fait que des entreprises signent et cosignent des applications est, dans l’absolu, une marque de sécurité. Les mécanismes entourant ces pratiques permettent d’éliminer en partie des contraintes pour les clients. C’est tout au bénéfice desdites structures : un climat de confiance favorise notamment les achats dématérialisés.

Pour notre part, nous ferons deux observations. Premièrement, la vigilance reste primordiale, car en se plaçant comme garantes de l’intégrité et de l’authenticité des applications qu’elles délivrent, les plateformes promettent un espace sécurisé. Ce fut souvent le cas de Google notamment face à certaines menaces sur Android : lumières braquées sur le Play Store et ses protections. Mais l’histoire a montré que même Google ne pouvait pas empêcher les malwares d’entrer dans le circuit. Idem chez Apple. La vérification reste donc de rigueur.

Deuxièmement, l’utilisateur devrait toujours avoir le choix, quel que soit le positionnement du curseur choisi par l’entreprise. Les ordinateurs diffèrent des téléphones et tablettes par leur capacité à pouvoir exécuter n’importe quoi, n’importe quand. Si Apple décide de renforcer certains aspects de la sécurité de macOS, le client doit pouvoir s’en débarrasser si cette barrière nuit à son quotidien. Comme d’autres mesures avant, il devra alors être pleinement informé des risques.