Apple et OCSP

Apple
1

Bon à savoir, même si ça n’est vraiment pas surprenant :

On modern versions of macOS, you simply can’t power on your computer, launch a text editor or eBook reader, and write or read, without a log of your activity being transmitted and stored. (…) it’s been possible up until today to block this sort of stuff on your Mac using a program called Little Snitch (…). The version of macOS that was released today, 11.0, also known as Big Sur, has new APIs that prevent Little Snitch from working the same way. The new APIs don’t permit Little Snitch to inspect or block any OS level processes.

Autrement dit, fini sur MacOS le choix d’être surveillé ou non. C’est surveillance par défaut, non désactivable et transmission des infos en clair sur le réseau via des opérateurs tiers.

1 « J'aime »
2

Il faut qu’il arrête la parano à deux balles sur des sujets pas maîtrisés le monsieur…

3

Corrigez moi si j’ai mal compris, Apple imposerai cette surveillance pour pouvoir identifier les applications qui sont lancées et mieux luter contre les malwares.

4

C’est son domaine de compétence. Mais si c’est le tien aussi, perso je suis très intéressé par un contrepoint sur le sujet, si tu le maîtrises aussi, voire mieux.

En attendant, et quel que soit l’objectif visé, le fait d’empêcher l’utilisateur de choisir n’est rien d’autre qu’orwellien.

5

Comme dit par @CaptainDuper c’est le mécanisme de remonté d’information pour le blocage d’éventuel malware. C’est exactement le même fonctionnement que Windows Defender et j’imagine des équivalents sur Linux.
Si tu regarde en détails ce que le mec « voit » dans la remonté d’information, c’est grosso-modo ce qui remonte par n’importe quelle adresse IP depuis n’importe quel poste sur n’importe quel système. Le seul élément en plus qui est envoyé chez Apple c’est le hash de l’app en cours d’utilisation.

Donc en gros d’après l’article Apple est le grand méchant espion PRISM-compatible car il peut bloquer des apps malveillantes à la volé sur son système.

6

Si tu lis l’article, ce que dénonce son auteur n’est en rien ce que tu viens de lister. Les points qui posent problème sont :

  • l’utilisateur n’a pas le choix et ne peut pas désactiver le système
  • ces données personnelles (géoloc + usage horodaté de l’ordinateur) sont remontées en clair sur le réseau
  • ces données sont traitées en clair par un opérateur tiers
  • ces données sont mises à disposition de tiers

Pour une boîte dont le marketing est fondé sur le respect de la vie privée de ses utilisateurs, ça laisse hautement dubitatif.

1 « J'aime »
7

the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it
C’est a Apple uniquement que les infos sont destinés et pas un tiers.

Avec une adresse IP quoi qu’il en dise on ne remonte pas automatiquement à une position géographique précise. Les « bornage » sur les WiFi voisins sont beaucoup plus précis qu’une adresse IP, et ça tombe bien Apple propose la randomisation de MAC adresse WiFi pour éviter ce genre de géolocalisation non consentie.

These OCSP requests are transmitted unencrypted . Everyone who can see the network can see these, including your ISP and anyone who has tapped their cables.

Oui et ? Une grosse partie des données réseau qui sort d’un ordi ne sont pas encodée. Le FAI sur lequel vous êtes connecté va connaitre votre adresse IP, truc de fou !

These requests go to a third-party CDN run by another company, Akamai.

Akamai qui gère l’infra d’Apple depuis une éternité, et donc ? Il vont voir passer des adresses IP avec des hash… ok.
Et puis c’est tellement bien verrouillé qu’il suffit de modifier le fichier host pour « désactiver » l’espionnage.

J’aimerai seulement comprendre ce que les espions pourraient faire avec un hash d’application (qui donc je le rappel n’est pas l’application clairement indiquée) et une adresse IP qu’il ne pourraient pas déjà faire avec tout ce qui est déjà transmis en clair par n’importe quel appareil.

Apple (or anyone else) can, of course, calculate these hashes for common programs: everything in the App Store, the Creative Cloud, Tor Browser, cracking or reverse engineering tools, whatever.

Je pense que c’est cette partie là qui me pose le plus de problème, toute sa démonstration d’espionnage (involontaire ou non) repose sur ce raccourcis : « n’importe qui peut savoir quelle app est lancée », sauf qu’a aucun moment il n’explique comment il trouve l’app lancée à partir du hash. « Apple ou n’importe qui, peut bien sûr calculer ce hash pour les programme connus », ha oui et comment ? Mystère…

Les conclusions du mec c’est clairement de l’ordre du fantasme parano et pas de l’étude sérieuse.

Additionally, the OCSP traffic that macOS generates is not encrypted, which makes it perfect for military surveillance operations (which passively monitor all major ISPs and network backbones)

Oui il y a de l’espionnage par des services secret sur des éléments précis de réseau (le ré-emballage de certains routeurs Cisco avant livraison au client final en est la preuve) mais l’espionnage global de tous les FAI et interco d’internet, faut peut-être pas abuser.

1 « J'aime »
8

Remarque qui n’a pas pour but de dénigrer ton message, on dit « chiffrer » pour parler d’appliquer un algo de cryptographie, et « encoder » c’est pour le format des données (pour l’interopérabilité).

Par ailleurs, le problème n’est pas qu’une partie des données soit ou non chiffrées. C’est que là l’utilisateur n’a pas par design la possibilité d’éviter que ces données non chiffrées soient émises. Encore une fois, de la part d’une entreprise qui vante la protection des données personnelles, ça pose question. Quand bien même Evil Corp à côté ferait aussi la même chose (et ils le font), est-ce que ça rend le processus normal ? Tel que décrit dans l’article, moi je ne trouve pas.

En lisant ça je comprends que tu ne sais pas de quoi tu parles (et ce n’est pas péjoratif). Un hash n’est pas un chiffrement. Au mieux, les hashs sont salés, ce qui ne les rend pas sûrs pour autant (le salt n’étant en principe pas une donnée confidentielle sécurisée). L’article semble indiquer que les hash en question sont en plus des hashs dont on peut facilement faire une rainbow table :

Apple (or anyone else) can, of course, calculate these hashes for common programs: everything in the App Store, the Creative Cloud, Tor Browser, cracking or reverse engineering tools, whatever.

L’auteur ne donne pas plus de précisions. Mais si ce qu’il indique est vrai, alors tu peux considérer que c’est comme si le nom de l’application était en clair.

Tu peux ne pas me croire sur parole, encore une fois je ne parle que de cet article, et sous réserve que son auteur ne se trompe pas. Mais je parle d’expérience, ce genre de sujets rentre dans mon domaine d’expertise. J’attends justement avec intérêt de voir si d’autres experts en sécu vont en parler dans les jours qui viennent, et détailler ce que ce mec dit. Mais en attendant, ça fait vraiment amateur de la part d’Apple.

9

Je sais bien ce qu’est un hash ne t’inquiète pas pour moi (et oui chiffré au lieu d’encodé tu as raison, j’ai quand même évité le « crypté »). Ça reste que sa démonstration n’est quand même pas vraiment bonne et sa conclusion tirée par les cheveux.

10

Justement si jamais tu croises des articles sur le sujet, n’hésite pas à linker (même en MP si les modo trouvent que ça pollue trop la shoutbox).

11

Nice FUD à 2 balles :confused: … Ça prend environs 1000 fois moins de temps de faire une recherche correcte que de se lancer dans tes tirades…

https://blog.jacopo.io/en/post/apple-ocsp/

Accessoirement Little Snitch est updaté pour Big Sur depuis 3 semaines.

1 « J'aime »
12

Le FUD c’est un peu le fond de commerce des experts en sécurité, non ? (Ceci est un taunt…)

La zone de floue de J.Paul n’était donc pas anodine. Entre un hash de l’app et un hash d’une partie du certificat d’un dev on est pas exactement sur le même niveau d’exposition de la vie privée, surtout si l’envoie d’information n’est pas systématique à chaque lancement d’app.

J’en profite pour mettre en avant une alternative à LittleSnitch, je ne l’ai pas encore testé mais elle a l’air prometteuse. https://objective-see.com/products/lulu.html

13

L’article que tu link est super intéressant parce qu’il clarifie tout ce qui n’était pas dans l’article initial, et il confirme qu’il y a donc des problèmes de confidentialité. Les problèmes mentionnés dans le blog initial restent soulevés, et ne sont pas du pur FUD. Tout particulièrement le fait que le protocole ne soit pas chiffré (pas la couche transport HTTP, mais la couche protocole OCSP elle-même).

La RFC de l’OCSP :

A.1. Request
HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.

J’ai ajouté la graisse sur la phrase clé. Ici chez Apple ce n’est pas le cas.

Autrement dit, avec cet article, on sait que n’importe quel Mac va leaker les certificats dév des applis installées. Ce n’est pas stricto sensu leaker les ID d’applications eux-mêmes, mais c’est quand même très proche.

Et qu’il existe une solution technique, à la charge de l’utilisateur averti, pour gérer la situation via Little Snitch ou via la résolution DNS, ça reste vraiment pas terrible pour une entreprise qui encore une fois fait sa communication sur la confidentialité.

14

Non ce n’est pas proche. Un certificat Adobe ou Microsoft ça peut correspondre à 30 apps différentes. Et en plus le « leak » n’est pas systématique à chaque lancement d’app

On est bien sur du « may » et pas du « must ».

Il faut peut-être aussi rappelé que macOS est un système grand public, on est pas sur Kali.

15

Les mots « MAY » / « MUST » etc. dans les RFC indique des options ou contraintes de la norme. Ici « MAY » indique que le protocole ne force pas le chiffrement. Mais la RFC indique clairement qu’en l’absence de chiffrement, la confidentialité n’existe pas.

Pour le reste, je ne connais pas l’implémentation des certifs de dév chez Apple, donc je ne me prononcerai pas avec certitude sur le sujet. Mais en soi, c’est déjà une fuite de données personnelles.

16

Rien que pour le nom de la boite je boycotte. Ça sent les mecs salés un peu… :wink:

C’est faux et pas ce que dit l’article justement. Le thread linké plus haut est également très clair. Pour ce qui est de l’IP, je te rappelle que même moi j’ai l’intégralité de tes logs de connexion / devices… Donc si, ça reste du FUD alarmiste, qui oublie la RAISON de l’existence du truc. En revanche ce cafouillage pointe du doigt une problématique technique intéressante. Point.

17

C’est pas très RGPD compliant ça !! :stuck_out_tongue:

18

Ah si justement (en vrai on rien de tout ça, c’était pour montrer à quel point il est facile de raconter de la merde). Le seul truc obligatoire pour nous c’est la dernière adresse IP associée à un message vu que RGPD ou pas, si un mec se pointe en gueulant "mort aux [insert whatever truc raciste ici], on doit être en mesure de filer l’info aux autorités si besoin (pratique ces lois qui se marchent dessus hein…)

1 « J'aime »
19

Sauf erreur de ma part l’analogie de @Cafeine ne porte pas sur le fond technique (la fuite technique de données), mais sur l’analyse qu’en fait le blog. Note : perso je ne suis pas non plus 100% en phase avec ce que le mec dit. Mais justement puisqu’on parle de RGPD, c’est une excellente grille de lecture pour parler du sujet.

La RGPD n’empêche pas de stocker des infos personnelles, comme une adresse email ou une IP. Elle pose les principes de ce qui est un compromis raisonnable entre l’objectif du traitement de données personnelles et l’impact sur la vie privée (c’est le coeur de ce que dit @Cafeine, sauf erreur de ma part là encore, je ne cherche pas à déformer les propos).

Data protection principles

If you process data, you have to do so according to seven protection and accountability principles outlined in Article 5.1-2:

  1. Lawfulness, fairness and transparency — Processing must be lawful, fair, and transparent to the data subject.
  2. Purpose limitation — You must process data for the legitimate purposes specified explicitly to the data subject when you collected it.
  3. Data minimization — You should collect and process only as much data as absolutely necessary for the purposes specified.
  4. Accuracy — You must keep personal data accurate and up to date.
  5. Storage limitation — You may only store personally identifying data for as long as necessary for the specified purpose.
  6. Integrity and confidentiality — Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (e.g. by using encryption).
  7. Accountability — The data controller is responsible for being able to demonstrate GDPR compliance with all of these principles.

Avec cette grille de lecture on voit bien pourquoi Geekzone peut stocker les IP et adresses emails, de manière raisonnable, sans être en infraction avec la RGPD. Et on retrouve avec le point 2 un des principaux arguments de @Cafeine.

En revanche, on voit aussi pourquoi le cas d’Apple pose des questions. Notamment sur le point 6 (quid de l’absence de confidentialité, si les données sont émises en clair pour être traitées par des tiers) ; les points 3 et 5 aussi (la collecte étant massive, on peut légitimement se demander si elle est accompagnée d’une durée de rétention raisonnable, surtout si Apple a passé un accord pour transmettre ces données à des tiers) ; et au moins un peu le point 1 (puisque l’utilisateur ne peut pas de manière simple éviter cette collecte, même en connaissance du risque pris en contrepartie, genre un gros « warning: vous ne devriez surtout pas désactiver ça »).

20

La question, elle est vite répondue (:man_facepalming:). Déjà y’a pas de collecte (c’est un check et basta), ensuite Apple ne bosse jamais avec des tiers sur ce genre de truc (les devs ont même pas accès à leur base clients via les stores je rappelle). Donc non y’a pas de Warning. Again, FUD et mauvaise connaissance du problème.