Et sans même parler des problèmes évidents liés aux concepts obsolètes de vie privée et de maîtrise de sa propre machine, voici un exemple de problème pratique posé par cette politique :
Pendant plusieurs heures, impossible de lancer la moindre application sur un Mac parce que Apple n’est pas fichu d’encaisser le Distributed Denial of Service au centre duquel la compagnie s’est elle-même placée en demandant à toutes ses machines de la contacter. Admirez une des plus grosses boîtes d’IT au monde, mesdames et messieurs.
Aujourd'hui c'est un scandale sur linuxfr. Mais demain, ce sera oublié même ici. On continuera à prendre RMS pour un illuminé et quiconque refuse — autant qu'il le peut — d'installer du code non-libre sur ses machines pour un abruti. Pourtant l'origine du mal n'est-elle pas là ? Pourquoi ferait-on confiance à des gens qui prétendent la main sur le cœur n'avoir rien à cacher mais qui refusent de montrer le code qu'ils vous demandent d’exécuter ? Personnellement, je me sens mal quand un quidam d'une ou l'autre DSI essait de m'imposer ce genre de pratique. Et j'ai l'impression que c'est vraiment la source du problème. Chacun considère que — peut-être parce qu'il lui est impossible de lire tout le code qu'il utilise — il est normal d'installer des blobs ; et symétriquement — parce qu'on ne maîtrise pas son ordinateur — on trouve normal de laisser autrui le contrôler, où d'envoyer directement ses données sur l'ordinateur d'un autre (coucou cher claude).
Tout juste peut-on se réjouir que tant de gens néfastes trouvent leur intérêt à envoyer des courriels de phishing, je suis prêt à parier qu'il en irait de même pour la transmission d'identifiants par courriel, et le clique sur les liens de ces derniers, qu'imposeraient vertement toutes les DSI un peu bancales si même M. et Mme Michu n'avaient fini par comprendre qu'il s'agit d'actions à proscrire.
Tout de même une chose m'intrigue dans ce problème de déni de service distribué chez la pomme. Comment se comportent les ordinateurs de cette dernière s'ils sont connectés à un réseau ne permettant pas d'apple_er leur maître ?
D'après la description, non connectés ils fonctionnent sans problème. Mais s'ils sont connecté à un réseau sans accès vers leur centre de contrôle ? N'essaient-ils pas de communiquer ? Ne devraient-ils pas alors avoir le même problème que quand leur CCC dysfonctionne ?
Posté par gouttegd .
Évalué à 10.
Dernière modification le 14 novembre 2020 à 20:45.
Comment se comportent les ordinateurs de cette dernière s'ils sont connectés à un réseau ne permettant pas d'apple_er leur maître ?
D'après la description, non connectés ils fonctionnent sans problème. Mais s'ils sont connecté à un réseau sans accès vers leur centre de contrôle ?
S’il n’est pas possible de contacter le service (parce que pas d’accès à Internet, ou parce que les connexions vers le serveur sont bloquées d’une manière ou une autre sur le trajet), il ne se passe rien : la vérification échoue en mode soft-fail et, dans le doute, Mac OS X autorise l’application à se lancer.
Mais s’il est possible de contacter le serveur mais que celui-ci échoue à répondre, alors Mac OS X attend indéfiniment, tout simplement.
En clair, ces génies de chez Apple ont apparemment bien prévu le coup que les autres gens, tous ceux situés entre l’utilisateur et Apple (par exemple les différents opérateurs réseaux) pouvaient merder et qu’il leur fallait gérer ça gracieusement, mais l’idée que leur propre service puisse être en rade (atteignable via le réseau mais pas en état de répondre) ne leur est jamais venu à l’esprit… Ou s’ils y ont pensé ils ont immédiatement éliminé l’hypothèse comme absurde…
S'il est avéré que les ordinateurs à la pomme se comportent comme décrit dans l'article, comment se fait-il qu'ils n'aient pas été immédiatement banni par des agences comme l'Anssi de tout usage un tant soit peu sensible ?
Certes, mais apparemment sans rapport avec le problème évoqué par l’article, non ? Plutôt des inquiétudes de compatibilité avec des logiciels pas encore testés sous cette nouvelle itération, ou avec les nouvelles architectures de machines. Soit que ce genre d’espionnage passe pour tout à fait normal désormais, soit qu’il s’agisse d’un article de désinformation.
S'il est avéré que les ordinateurs à la pomme se comportent comme décrit dans l'article
Ce comportement est avéré. Apple ne s’en cache même pas d’ailleurs, c’est une feature, pas un bug. Le but est supposément d’empêcher l’exécution de malware.
L’incident du 12 novembre a seulement mis en évidence une des conséquences possibles de ce comportement (parmi d’autres), mais il était déjà bien connu.
Quant à savoir pourquoi tout le monde s’en fich(e|ait), boaf… je dirais simplement que plus rien ne m’étonne.
À ma connaissance, aucune. C’est le même protocole, il est juste utilisé dans un but différent.
Les clients web utilisent OCSP pour vérifier que le certificat d’un site web n’a pas été révoqué avant de continuer à s’y connecter ; Mac OS X utilise OCSP pour vérifier que le certificat d’une application n’a pas été révoqué avant de l’autoriser à s’exécuter.
Posté par gouttegd .
Évalué à 9.
Dernière modification le 15 novembre 2020 à 22:30.
Absolument, c’est l’un des problèmes du protocole OCSP appliqué aux sites web.
C’est pourquoi aujourd’hui on recommande une variation du protocole, l’agrafage OCSP (OCSP stapling). Le principe est que c’est le serveur web (et non plus le client du visiteur) qui effectue périodiquement (tous les quelques jours en moyenne) une requête OCSP auprès de la CA qui a délivré le certificat ; la réponse OCSP est alors « agrafée » au certificat, pour être présentée au client en même temps que le certificat lui-même lors de l’établissement de la connexion TLS.
En gros, avec OCSP « normal », on a :
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà.
— Client : Hello CA, ce certificat que tu as émis est-il toujours valide ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste.
— Client : OK Serveur, voilà ma requête.
Alors qu’avec l’agrafage OCSP, on a :
— Serveur : Hello CA, mon certificat est toujours valide, hein ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste, valable 7 jours.
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà, avec en prime une attestation de la CA, de moins de 7 jours, qui dit qu’il est toujours valide.
— Client : OK Serveur, voilà ma requête.
L’agrafage OCSP résout deux problèmes majeurs d’OCSP :
le problème de vie privée que tu mentionnes (désormais les requêtes OCSP proviennent des serveurs web et non plus des visiteurs desdits serveurs) ;
la vulnérabilité induite par le fait qu’on peut faire un DDoS sur le serveur OCSP de la CA et ainsi soit provoquer un déni de service indirect sur le serveur web (si les clients sont configurés en mode hard-fail, il suffit de faire tomber le serveur OCSP pour interdire toute connexion au serveur web), soit rendre la vérification OCSP inutile (si les clients sont configurés en mode soft-fail, en faisant tomber le serveur OCSP on interdit toute vérification effective de la validité du certificat).
Mais l’agrafage OCSP n’est pas vraiment applicable dans le cas où les certificats sont utilisés pour authentifier des applications et non des serveurs web…
Si l'ANSSI était aussi sérieuse, ça fait longtemps qu'on n'autoriserait que des applis sur un store géré par l'ANSSI (opensource compilées par l'ANSSI, ou proprio mais avec un accès au code par l'ANSSI et encore une fois compilées par l'ANSSI).
Si c'est pour récupérer des infos, on peut très bien imaginer que le système attende patiemment un contact volontaire avec la maison-mère pour glisser quelques données dans l'échange (mise à jour système, installation d'appli ou autre prétexte). Ça serait certainement plus discret.
D'après un article discuté sur HN (https://news.ycombinator.com/item?id=25095438), ce sont les infos sur le certificat du développeur de l'application et non un hash de celle-ci qui sont envoyées en clair à Apple.
# Conséquences
Posté par gouttegd . Évalué à 10.
Et sans même parler des problèmes évidents liés aux concepts obsolètes de vie privée et de maîtrise de sa propre machine, voici un exemple de problème pratique posé par cette politique :
https://arstechnica.com/gadgets/2020/11/macos-big-sur-launch-appears-to-cause-temporary-slowdown-in-even-non-big-sur-macs/
Pendant plusieurs heures, impossible de lancer la moindre application sur un Mac parce que Apple n’est pas fichu d’encaisser le Distributed Denial of Service au centre duquel la compagnie s’est elle-même placée en demandant à toutes ses machines de la contacter. Admirez une des plus grosses boîtes d’IT au monde, mesdames et messieurs.
[^] # Re: Conséquences
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Aujourd'hui c'est un scandale sur linuxfr. Mais demain, ce sera oublié même ici. On continuera à prendre RMS pour un illuminé et quiconque refuse — autant qu'il le peut — d'installer du code non-libre sur ses machines pour un abruti. Pourtant l'origine du mal n'est-elle pas là ? Pourquoi ferait-on confiance à des gens qui prétendent la main sur le cœur n'avoir rien à cacher mais qui refusent de montrer le code qu'ils vous demandent d’exécuter ? Personnellement, je me sens mal quand un quidam d'une ou l'autre DSI essait de m'imposer ce genre de pratique. Et j'ai l'impression que c'est vraiment la source du problème. Chacun considère que — peut-être parce qu'il lui est impossible de lire tout le code qu'il utilise — il est normal d'installer des blobs ; et symétriquement — parce qu'on ne maîtrise pas son ordinateur — on trouve normal de laisser autrui le contrôler, où d'envoyer directement ses données sur l'ordinateur d'un autre (coucou cher claude).
Tout juste peut-on se réjouir que tant de gens néfastes trouvent leur intérêt à envoyer des courriels de phishing, je suis prêt à parier qu'il en irait de même pour la transmission d'identifiants par courriel, et le clique sur les liens de ces derniers, qu'imposeraient vertement toutes les DSI un peu bancales si même M. et Mme Michu n'avaient fini par comprendre qu'il s'agit d'actions à proscrire.
Tout de même une chose m'intrigue dans ce problème de déni de service distribué chez la pomme. Comment se comportent les ordinateurs de cette dernière s'ils sont connectés à un réseau ne permettant pas d'apple_er leur maître ?
D'après la description, non connectés ils fonctionnent sans problème. Mais s'ils sont connecté à un réseau sans accès vers leur centre de contrôle ? N'essaient-ils pas de communiquer ? Ne devraient-ils pas alors avoir le même problème que quand leur CCC dysfonctionne ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Conséquences
Posté par gouttegd . Évalué à 10. Dernière modification le 14 novembre 2020 à 20:45.
S’il n’est pas possible de contacter le service (parce que pas d’accès à Internet, ou parce que les connexions vers le serveur sont bloquées d’une manière ou une autre sur le trajet), il ne se passe rien : la vérification échoue en mode soft-fail et, dans le doute, Mac OS X autorise l’application à se lancer.
Mais s’il est possible de contacter le serveur mais que celui-ci échoue à répondre, alors Mac OS X attend indéfiniment, tout simplement.
En clair, ces génies de chez Apple ont apparemment bien prévu le coup que les autres gens, tous ceux situés entre l’utilisateur et Apple (par exemple les différents opérateurs réseaux) pouvaient merder et qu’il leur fallait gérer ça gracieusement, mais l’idée que leur propre service puisse être en rade (atteignable via le réseau mais pas en état de répondre) ne leur est jamais venu à l’esprit… Ou s’ils y ont pensé ils ont immédiatement éliminé l’hypothèse comme absurde…
[^] # Re: Conséquences
Posté par Glandos . Évalué à 2.
Comme la cible
-j DROPdeiptables? C'est rigolo de faire un déni de service Apple.# Question bête
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7.
S'il est avéré que les ordinateurs à la pomme se comportent comme décrit dans l'article, comment se fait-il qu'ils n'aient pas été immédiatement banni par des agences comme l'Anssi de tout usage un tant soit peu sensible ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Question bête
Posté par lejocelyn (site web personnel) . Évalué à 3.
Dans mon labo, on a reçu un message de la direction du CNRS nous enjoignant à ne pas installer la dernière itération de l'OS d'Apple pour le moment.
[^] # Re: Question bête
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Certes, mais apparemment sans rapport avec le problème évoqué par l’article, non ? Plutôt des inquiétudes de compatibilité avec des logiciels pas encore testés sous cette nouvelle itération, ou avec les nouvelles architectures de machines. Soit que ce genre d’espionnage passe pour tout à fait normal désormais, soit qu’il s’agisse d’un article de désinformation.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Question bête
Posté par gouttegd . Évalué à 6.
Ce comportement est avéré. Apple ne s’en cache même pas d’ailleurs, c’est une feature, pas un bug. Le but est supposément d’empêcher l’exécution de malware.
L’incident du 12 novembre a seulement mis en évidence une des conséquences possibles de ce comportement (parmi d’autres), mais il était déjà bien connu.
Quant à savoir pourquoi tout le monde s’en fich(e|ait), boaf… je dirais simplement que plus rien ne m’étonne.
[^] # Re: Question bête
Posté par flan (site web personnel) . Évalué à 2.
Quelle est la différence avec ce même OCSP qui est utilisé sur les certificats de sites web ?
[^] # Re: Question bête
Posté par gouttegd . Évalué à 3.
À ma connaissance, aucune. C’est le même protocole, il est juste utilisé dans un but différent.
Les clients web utilisent OCSP pour vérifier que le certificat d’un site web n’a pas été révoqué avant de continuer à s’y connecter ; Mac OS X utilise OCSP pour vérifier que le certificat d’une application n’a pas été révoqué avant de l’autoriser à s’exécuter.
[^] # Re: Question bête
Posté par flan (site web personnel) . Évalué à 2.
Du coup, ça veut dire que l'émetteur du certificat est capable de dire quels sont les sites visités par les IP des visiteurs.
[^] # Re: Question bête
Posté par gouttegd . Évalué à 9. Dernière modification le 15 novembre 2020 à 22:30.
Absolument, c’est l’un des problèmes du protocole OCSP appliqué aux sites web.
C’est pourquoi aujourd’hui on recommande une variation du protocole, l’agrafage OCSP (OCSP stapling). Le principe est que c’est le serveur web (et non plus le client du visiteur) qui effectue périodiquement (tous les quelques jours en moyenne) une requête OCSP auprès de la CA qui a délivré le certificat ; la réponse OCSP est alors « agrafée » au certificat, pour être présentée au client en même temps que le certificat lui-même lors de l’établissement de la connexion TLS.
En gros, avec OCSP « normal », on a :
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà.
— Client : Hello CA, ce certificat que tu as émis est-il toujours valide ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste.
— Client : OK Serveur, voilà ma requête.
Alors qu’avec l’agrafage OCSP, on a :
— Serveur : Hello CA, mon certificat est toujours valide, hein ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste, valable 7 jours.
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà, avec en prime une attestation de la CA, de moins de 7 jours, qui dit qu’il est toujours valide.
— Client : OK Serveur, voilà ma requête.
L’agrafage OCSP résout deux problèmes majeurs d’OCSP :
Mais l’agrafage OCSP n’est pas vraiment applicable dans le cas où les certificats sont utilisés pour authentifier des applications et non des serveurs web…
[^] # Re: Question bête
Posté par Maclag . Évalué à 6.
Si l'ANSSI était aussi sérieuse, ça fait longtemps qu'on n'autoriserait que des applis sur un store géré par l'ANSSI (opensource compilées par l'ANSSI, ou proprio mais avec un accès au code par l'ANSSI et encore une fois compilées par l'ANSSI).
Si c'est pour récupérer des infos, on peut très bien imaginer que le système attende patiemment un contact volontaire avec la maison-mère pour glisser quelques données dans l'échange (mise à jour système, installation d'appli ou autre prétexte). Ça serait certainement plus discret.
[^] # Re: Question bête
Posté par flan (site web personnel) . Évalué à 2.
Autoriser ou interdire… à qui ?
Dans quel domaine ?
# Un détail
Posté par Mackenzie . Évalué à 3.
D'après un article discuté sur HN (https://news.ycombinator.com/item?id=25095438), ce sont les infos sur le certificat du développeur de l'application et non un hash de celle-ci qui sont envoyées en clair à Apple.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.