Ce qui arrive sur votre Mac ne reste pas toujours sur votre Mac, Réactions à la publication du 15/11/2020

[Rédaction]

... et c'est encore moins le cas avec l'arrivée de Big Sur.

Vous avez peut-être remarqué sur votre Mac un ralentissement du lancement des applications ces derniers jours. Un ralentissement dû à une fonctionnalité de sécurité de macOS.

Introduite il y a deux ans, cette fonctionnalité consiste à envoyer à un serveur d'Apple (ocsp.apple.com) la signature unique du fichier exécutable de chaque application que vous tentez d'exécuter sur votre Mac. En réponse, le serveur indique au Mac si l'application en question peut ou non être lancée.

Si le serveur est injoignable (Mac non connecté à Internet ou requête bloquée par un pare-feu), l'application se lance immédiatement. S'il est joignable, elle n'est lancée qu'une fois qu'une réponse positive a été reçue. Ainsi, en cas de surcharge des serveurs, comme c'est arrivé les 12 et 13 novembre, l'allongement du temps de réponse du serveur provoque le ralentissement du lancement des applications, constaté par de nombreux utilisateurs.

Un dysfonctionnement qui tombe particulièrement mal, alors même qu'Apple vient de sortir macOS Big Sur, qui rend plus compliqué la désactivation de ce système. En effet, s'il n'y a jamais eu d'option officielle permettant de la désactiver, cette fonctionnalité pouvait jusqu'à présent être bloquée avec un pare-feu installé sur le Mac, comme LittleSnitch. Ce n'est plus possible sous Big Sur, qui a mis en place une protection de certains processus système : leurs requêtes réseau ne peuvent plus être filtrées par un pare-feu local, ni passer par certains VPN (un VPN virtuel aurait aussi permis de les bloquer localement).

Il semblerait que pour l'instant le blocage soit encore possible via le fichier /etc/hosts, en y ajoutant une entrée pour faire pointer ocsp.apple.com vers 127.0.0.1. Mais pour combien de temps ?

Venant d'Apple, qui se présente régulièrement comme un défenseur de la vie privée, ces restrictions sont en tout cas particulièrement mal venues, d'autant plus que les données sont transmises en clair et que les requêtes transitent par des serveurs n'appartenant pas à Apple (Apple utilise les services d'Akamai pour mieux absorber la charge), ce qui donne une grande surface d'attaque pour intercepter les requêtes et déterminer les logiciels utilisés par les Mac situés derrière une IP publique donnée, mais aussi, de deviner de manière indirecte d'autres informations : profession, horaires de travail, période de congé, loisirs…

Pire, l'absence de chiffrement pourrait éventuellement ouvrir à un attaquant la possibilité de déterminer quelles applications il vous autorise à utiliser sur votre Mac, en renvoyant des réponses négatives aux requêtes qu'il aura réussi à intercepter (ce n'est toutefois pas trivial, la réponse étant normalement signée par le serveur)…

MàJ : la signature envoyée est en fait propre à chaque développeur/éditeur, et non à chaque application, ce qui limite un peu la portée des informations pouvant être récupérées (l'attaquant peut par exemple déterminer que vous utilisez des logiciels Adobe et Microsoft, mais pas lesquels précisément).


Lien vers le billet original

[flan]

Vu le nom de domaine, c'est un serveur OCSP, à qui le numéro de série d'un certificat (en l'occurrence celui de l'éditeur du logiciel) est envoyé et qui répond si le certificat est encore valide ou s'il a été révoqué.

Et il y a exactement le même système pour beaucoup de certificats SSL (c'est par exemple le cas sur le certificat de MacBidouille : Digicert peut savoir que votre adresse IP fréquente MacBidouille).

[downanotch]

Vu le nom de domaine, c'est un serveur OCSP, à qui le numéro de série d'un certificat (en l'occurrence celui de l'éditeur du logiciel) est envoyé et qui répond si le certificat est encore valide ou s'il a été révoqué.

Et il y a exactement le même système pour beaucoup de certificats SSL (c'est par exemple le cas sur le certificat de MacBidouille : Digicert peut savoir que votre adresse IP fréquente MacBidouille).

C'est exactement ça, Jeffrey Paul n'a pas tout compris : https://blog.jacopo.io/en/post/apple-ocsp/

Ci dessous le TL;DR du lien ci-dessus :

• Non, macOS n'envoie pas à Apple un hash de vos applications chaque fois qu'elle sont lancées
• Vous devez être au courant que macOS peut transmettre des informations opaques à propose du certificat développeur des applications que vous utilisez. Ces informations sont envoyées en clair sur votre réseau
• Vous ne devriez probablement pas bloquer ocsp.apple.com avec Little Snitch ou dans votre fichier host.

Ce message a été modifié par downanotch - 15 Nov 2020, 21:10.

[iAPX]

Vu le nom de domaine, c'est un serveur OCSP, à qui le numéro de série d'un certificat (en l'occurrence celui de l'éditeur du logiciel) est envoyé et qui répond si le certificat est encore valide ou s'il a été révoqué.

Et il y a exactement le même système pour beaucoup de certificats SSL (c'est par exemple le cas sur le certificat de MacBidouille : Digicert peut savoir que votre adresse IP fréquente MacBidouille).

C'est exactement ça, Jeffrey Paul n'a pas tout compris : https://blog.jacopo.io/en/post/apple-ocsp/

Ci dessous le TL;DR du lien ci-dessus :

• Non, macOS n'envoie pas à Apple un hash de vos applications chaque fois qu'elle sont lancées
• Vous devez être au courant que macOS peut transmettre des informations opaques à propose du certificat développeur des applications que vous utilisez. Ces informations sont envoyées en clair sur votre réseau
• Vous ne devriez probablement pas bloquer ocsp.apple.com avec Little Snitch ou dans votre fichier host.

C'est très intéressant, incluant le problème d'authentification TLS qui est récursif.

Après examen ça n'est d'ailleurs pas ocsp.apple.com qui est toujours employé, par exemple dans mon cas ocsp-lb.apple.com.akadns.net et ocsp.g.applimg.com, sans pouvoir vérifier aisément le contenu des échanges à l'instant (donc peut-être certains créés par Chrome, mais peu probable vu les domaines), ces appels ont été effectués aux lancements de logiciels de différents éditeurs sur mon Mac sous macOS 11 Big Sur.

OCSP est amusant, je n'y avais pas réfléchi plus en profondeur et surtout pas dans le contexte des signatures de nos Apps.
Le problème de fond est que c'est une sécurité pour pouvoir désactiver des applications suite à la révocation d'un certificat développeur, mais que d'un autre coté ça transmet des informations, incluant des PII au sens du GDPR/RGPD, et des informations -certes partielles- sur nos usages qui peuvent avoir de la valeur sur le long-terme.

Attendons de voir ce que Apple en dit, et aussi les analyses techniques qui devraient suivre, mais essentiellement si on veut bénéficier de la possibilité de profiter de la -rare- révocation de certificats (et pas nécessairement à bon escient!!!) il me paraît très compliqué de ne pas envoyer d'informations révélatrices, au moins pour Apple.

Apple pourrait au moins chiffrer les informations de manière asymétrique (avec une partie de la payload pseudo-aléatoire), mais là arriverait le problème de maintenance nécessaire de la clé de chiffrement publique en cas de fuite de la clé privée, mais ça pourrait être un bon compromis à mon sens.

PS: @SartMatt propose plus haut que ça puisse être désactivable, ce qui enlève une sécurité très rarement utilisée, mais offre un bien meilleur respect de la vie privé, et je pense que ça serait une bonne chose.
Pour ma part je vais filtrer cela car ça rentre dans ma catégorie Traceurs et malware divers.

Ce message a été modifié par iAPX - 16 Nov 2020, 04:13.