- Android 14 (API v34) change la lecture des certificats CA système : ils ne sont plus lus depuis
/system, mais depuis le modulecom.android.conscryptbasé sur APEX, ce qui casse le flux de débogage habituel qui injectait des certificats avec les droits root - Depuis Android 7 Nougat, le magasin de confiance par défaut des applications est séparé entre CA système et CA utilisateur, si bien que les outils de développement, de test et de reverse engineering dépendaient de la modification directe du répertoire des CA système
- Cette nouvelle architecture permet de mettre à jour les certificats CA via Google Play System Update, ce qui accélère la suppression des CA problématiques et le déploiement de nouvelles CA, mais réduit le contrôle du propriétaire de l’appareil
- Sur l’émulateur bêta d’Android 14, même en masquant par tmpfs ou en supprimant
/system/etc/security/cacerts,/system/etc/security/cacerts_google,/apex/com.android.conscrypt/cacerts, etc., Settings et les applications continuent de voir la liste des CA de Google - Au moment de la rédaction, les alternatives réalistes étaient de rester sur Android 13 ou d’utiliser un OS personnalisé qui n’emploie pas APEX, et l’auteur précise que des méthodes de contournement pour injecter des certificats sur Android 14 sont ensuite apparues
Évolution de la gestion des CA sur Android
- Lors de l’annonce de l’Open Handset Alliance en 2007, Android mettait en avant son ouverture avec des formulations comme « open platform » et « complete access to handset capabilities and tools »
- Avec le temps, la capacité des utilisateurs, développeurs et chercheurs à contrôler leur propre appareil s’est progressivement réduite, selon cette analyse
-
Le tournant d’Android 7 Nougat
- La liste des CA que le propriétaire de l’appareil pouvait modifier a été scindée entre CA système et CA utilisateur
- La liste fixe des CA système fournie par l’éditeur de l’OS est devenue la valeur par défaut pour toutes les applications
- La liste des CA modifiable par l’utilisateur n’est utilisée que si l’application y adhère explicitement
- Résultat : presque toutes les applications ont cessé de faire confiance aux CA utilisateur par défaut
Pourquoi les certificats CA sont importants
- Les CA de confiance d’un appareil sont la liste des organisations qui garantissent la sécurité du trafic réseau chiffré
- Une CA peut émettre des certificats pour n’importe quel domaine à utiliser dans des connexions TLS comme HTTPS, et tout appareil qui lui fait confiance considérera ces certificats comme une preuve de connexion légitime
- Si un utilisateur fait reconnaître à l’appareil une CA qu’il a créée lui-même, il peut intercepter et inspecter son propre trafic HTTPS ou TLS
- Il peut voir les données envoyées et reçues par le téléphone
- Et, si nécessaire, les modifier ou les bloquer
- Ce niveau de contrôle est important pour la recherche en sécurité et en confidentialité, le reverse engineering, le débogage et les tests d’applications, la configuration de réseaux internes d’entreprise et les utilisateurs qui ne veulent pas faire confiance aux CA par défaut
- Il est raisonnable d’empêcher qu’un utilisateur non technique modifie une CA par erreur ou qu’elle soit changée à son insu, mais limiter aussi le contrôle des utilisateurs avancés complique de nombreux usages
Méthodes de contournement basées sur root depuis Android 7
- Même après Android 7, il restait possible de manipuler directement le magasin de CA système sur un appareil disposant des droits root
- La méthode la plus courante consistait à placer le certificat de confiance dans
/system/etc/security/cacerts/ - Comme
/systemest généralement en lecture seule, même sur les appareils rootés, deux approches étaient utilisées- Reconfigurer le répertoire
/systemen écriture, redémarrer, puis modifier le vrai répertoire des certificats système - Monter un système de fichiers temporaire en lecture/écriture au-dessus du répertoire en lecture seule, copier les CA existantes, puis ajouter le nouveau certificat
- Reconfigurer le répertoire
- Pour qu’un certificat soit accepté par le système, il fallait aussi respecter des contraintes comme le nom de fichier, les permissions et le label SELinux
- HTTP Toolkit automatisait cette procédure fondée sur un montage temporaire afin de proposer une configuration d’interception en un clic sur les appareils Android rootés et les émulateurs
- Cette approche fonctionnait sur la plupart des appareils rootés personnalisés, distributions Android spécialisées et images d’émulateur officielles de Google
- Les images full « Google Play », verrouillées comme les appareils OEM classiques, faisaient exception
- La documentation de configuration de mitmproxy, de nombreux articles de blog, réponses StackOverflow, messages de forum, paquets Magisk et guides de cacert.org reposaient sur des méthodes similaires
La nouvelle architecture de mise à jour des CA dans Android 14
- Android 14 était, au moment de l’écriture, en phase bêta finale et devait sortir dans les semaines suivantes
- L’une de ses principales fonctions de sécurité est la mise à jour à distance des certificats CA
- La gestion des certificats CA a été séparée de l’image principale de l’OS pour être déplacée vers un composant distinct, distribué et mis à jour via Google Play
- Avec cette architecture, Google peut retirer plus rapidement sa confiance à une CA problématique
- Il n’est plus autant nécessaire d’attendre qu’un fabricant de téléphones diffuse une mise à jour OTA complète de l’OS
- Une simple Google Play System Update peut modifier la liste des CA sur les appareils Android 14+
- Les CA de confiance par défaut disposent de privilèges puissants, ce qui exige supervision et sanctions, et les privilèges d’une CA défaillante doivent pouvoir être retirés rapidement
- Exemple : en janvier 2023, TrustCor a perdu la confiance de grands acteurs, dont Google, après la découverte de liens étroits avec une organisation de diffusion de malware et des sous-traitants américains de la défense et du renseignement
- À l’inverse, retarder le déploiement d’une nouvelle CA pose aussi problème
- Let’s Encrypt a dû repousser à plusieurs reprises l’amélioration de sa chaîne de signature parce que d’anciens appareils Android ne disposaient pas de la CA racine la plus récente
- L’idée d’une architecture plus réactive pour les mises à jour de CA a de la valeur, mais l’implémentation d’Android 14 rend en pratique très difficile la modification des CA système
Emplacement réel des fichiers et fonctionnement d’APEX
- Le changement clé d’Android 14 est que, si
/apex/com.android.conscrypt/cacertsexiste, les certificats sont lus à cet emplacement au lieu de/system/etc/security/cacerts /apexest le chemin où sont montés les conteneurs APEX (« Android Pony EXpress »)- Les modules APEX sont des composants système pouvant être mis à jour indépendamment, distribués sous forme de conteneurs immuables signés
- Dans Android 14, les certificats CA font partie du module
com.android.conscrypt, la bibliothèque TLS/SSL centrale d’Android - Le fonctionnement bas niveau d’APEX est insuffisamment documenté, et certains liens essentiels pointent, selon l’auteur, vers des sites internes à Google
- Les tests montrent que le contenu du module APEX est exposé directement à chaque processus, de sorte que modifier les fichiers ailleurs ne change pas ce que voient les applications
Ce qui a été observé sur l’émulateur Android 14
- Les images AOSP et « Play Services » de l’émulateur officiel bêta Android 14 permettent l’accès root
- L’image « Google Play » reste verrouillée, comme un appareil OEM classique
- Il est possible de créer un émulateur avec l’image API 34 « Google APIs » et d’ouvrir un shell root
- Avec l’ancienne méthode de montage temporaire, recouvrir par tmpfs les chemins suivants n’a pas produit l’effet attendu
/system/etc/security/cacerts/system/etc/security/cacerts_google/apex/com.android.conscrypt/cacerts/apex/com.android.conscrypt@340818022/cacerts
- Dans Settings → Security & Privacy → More → Encryption → Trusted Credentials, l’onglet « System » continue d’afficher les certificats qui étaient supposés être masqués
- Par exemple, si l’on recherche dans tout le système de fichiers le certificat « ACCV »
3c9a4d3b.0, il n’apparaît plus pendant que le montage le masque, mais il reste visible dans Settings - En répétant la même procédure sur une image Android 13, la liste des certificats dans Settings devient vide, ce qui montre que l’ancienne méthode fonctionne comme prévu
Même la modification directe de l’image système échoue
- Il est possible de démarrer l’émulateur Android 14 avec
-writable-system, puis d’activer l’écriture avecadb root,adb remount,avbctl disable-verification, redémarrage, etc. - Il devient alors possible de supprimer les certificats de
/system/etc/security/cacerts/*et/system/etc/security/cacerts_google/* - En revanche, il est impossible de supprimer les certificats présents dans
/apex- Ils restent en lecture seule même après le remount
- La commande
mount -o remount,rw ...échoue également
- La manipulation la plus proche possible consistait à faire un
umountdu chemin de certificat concerné pour qu’il disparaisse de la sortie demount - Malgré cela, la liste « Trusted » de Settings continue de charger les certificats CA
- L’auteur estime qu’il ne s’agit pas d’un simple problème de cache de l’application Settings, car le même comportement est observé du point de vue du magasin de certificats vu par les applications
- Quelle que soit la modification apportée au système de fichiers, les applications continuent apparemment de voir la liste des CA de Google
Impact et limites
- Dans Android 14, le flux habituel consistant à installer des certificats CA système pour le débogage, le reverse engineering, les tests et la recherche ne fonctionne plus avec les anciennes méthodes
- Au moment de la rédaction, les alternatives étaient de rester sur Android 13 ou d’utiliser une version personnalisée d’OS qui n’emploie pas de module APEX pour gérer les certificats CA
- Avec le temps, ces alternatives risquent de devenir de moins en moins pratiques, car elles s’éloignent des composants internes centraux d’Android Mainline ou imposent de continuer à utiliser des logiciels anciens
- Si le contenu des modules APEX est impossible à modifier, même avec les droits root, chaque composant système migré vers APEX pourrait à l’avenir réduire davantage le contrôle utilisateur
- Cela peut aussi poser problème à des forks Android comme GrapheneOS et LineageOS, ainsi qu’à Magisk et à divers modules
- Cela dit, comme l’indique la mise à jour en tête d’article, les discussions et les recherches de contournement ont ensuite permis de trouver plusieurs solutions pour rétablir l’injection de certificats sur Android 14
- Pour déboguer le trafic HTTPS sur Android 14, il devient difficile de partir du principe que la seule injection rootée de CA système suffira
1 commentaires
Avis de Hacker News
Ayant travaillé avec d’anciens outils de root Android, des ROM custom modernes généralistes et diverses tâches liées à l’OS Android, je pense que le titre est faux, aujourd’hui comme à l’avenir
Sur Android, quand on parle de root, il s’agit bien de droits root, et on peut faire tout ce qu’on veut [1]
Magisk, le root Android actuel, inclut même une fonctionnalité permettant de « modifier » du code Java ; il devrait donc être possible d’y accéder même si c’est profondément enfoui
Le fait que l’auteur n’y soit pas parvenu ne signifie pas que ce soit impossible ; il est possible que zygote mette les CA en cache et doive être redémarré avec
stop;start, ou qu’il faille basculer vers le bon espace de noms de montage avant d’exécuter la commandeGrapheneOS et LineageOS ont accès à l’intégralité du code source, donc ils peuvent changer ce qu’ils veulent ; la contrainte se limite à la pénibilité de suivre tout ce que Google casse à une vitesse folle
J’espère qu’à mesure qu’Android devient de plus en plus hostile aux utilisateurs, surtout aux power users, davantage de personnes passeront aux ROM custom
Dans mes rêves, je créerais un fork d’Android du genre « OwnerDroid », dont la première ligne du modèle de sécurité ne serait pas « l’utilisateur est l’ennemi », mais je n’ai produit que quelques petites briques, et l’ensemble du projet demanderait une quantité de travail énorme
[1] à l’exception de certaines protections au niveau du noyau, mais GKI réduit ce risque
Ce n’est désormais plus possible
Bien sûr, avec tout le code source, tout est possible, et l’on peut aussi compiler de zéro une image système Android avec ce module désactivé ; GrapheneOS/LineageOS peuvent également s’adapter
Mais cela crée beaucoup de nouveau travail, et si l’on diverge de l’implémentation Android sur des composants essentiels, cela peut nécessiter encore plus de maintenance à l’avenir
Pour la grande majorité des utilisateurs concernés, « commencez par compiler vous-même l’image système » dépasse largement leur zone de confort et le niveau de temps qu’ils sont prêts à y consacrer
D’autres solutions finiront par émerger, mais elles consisteront probablement à fouiller dans les espaces de noms pour modifier individuellement les montages du processus cible, à compiler et installer son propre module APEX de manière approuvée par Android pour remplacer le module système, ou à hooker des apps individuelles avec Frida
Cela reste néanmoins un gros problème, car cela rend plus difficile pour l’utilisateur de garder le contrôle complet de son propre appareil
Les éléments importants, comme les vérifications de root des applications bancaires indispensables ou les fonctionnalités liées à Google, ne sont pas documentés, et il est presque impossible de trouver des informations indiquant qu’une combinaison « modèle de téléphone + application bancaire locale + ROM custom » a été testée et fonctionne bien
Je suis pour la liberté et le choix, mais pour l’utilisateur moyen de smartphone, ce n’est pas une démarche réaliste, sauf à investir plusieurs téléphones et plusieurs jours de travail, ou à être déjà expert
Je suis power user sur ordinateur, mais j’accepte que mon téléphone soit plus idiot
Cela devient toutefois difficile si l’on doit de plus en plus utiliser son téléphone comme appareil d’authentification multifacteur, ou si l’on se retrouve soumis aux caprices d’entreprises disposant d’un levier plus fort, comme les banques
Je n’ai pas l’intention de changer trois fois de compte bancaire pour trouver une application qui fonctionne sur un téléphone rooté
Si vous demandez « en quoi un fork d’Android serait-il un concurrent ? », c’est que la stratégie fonctionne
Si la nouvelle méthode lit les certificats depuis
/apex/com.android.conscrypt/cacertslorsqu’il existe, on pourrait probablement, comme pour les contournements SafetyNet actuels, la dissimulation du root ou le masquage de Magisk, cacher/apex/com.android.conscrypt/cacertsuniquement aux processus concernés afin de les faire revenir à l’ancien comportementC’est un domaine réservé aux hackers, et même parmi eux, seule une toute petite minorité les utilise
Il y a beaucoup de bons commentaires ici, mais je ne peux pas m’empêcher de penser à quel point il est heureux que les PC ne se comportent pas comme les smartphones
Android s’est tellement saboté lui-même que je me surprends à trouver étrange d’être reconnaissant que Microsoft ne gère pas le monde du PC comme Google gère celui du smartphone
Windows lui-même, comparé à Android, ressemble presque à un bastion de stabilité et de bon sens, et l’on n’est pas forcé de faire une mise à niveau avant que le matériel ne tombe réellement en panne de vieillesse
Comme Google, Microsoft ne contrôle pas toute la chaîne matériel-logiciel, mais il avait le pouvoir d’imposer des normes via le Store ou de décourager les modifications d’environnement par des mécanismes de type SafetyNet, rendant la possession d’un PC extrêmement pénible
Je ne me souviens plus très bien si Microsoft a déjà fait l’objet de poursuites antitrust pour ce genre de choses, mais je me demande quand il en ira de même pour Google
Microsoft a aussi ajouté quantité de DRM à Windows, puis en a supprimé certains par la suite, et l’attestation à distance est également intégrée à l’OS
Google a modifié une implémentation interne d’Android sur laquelle il n’aurait de toute façon pas fallu s’appuyer, ce qui gêne les développeurs, mais Microsoft fait ce genre de choses en permanence
Il y a de fortes chances qu’il suffise d’attendre quelques semaines un module Magisk mis à jour, et franchement, ce n’est pas si grave
Il suffit de ne pas appuyer sur le bouton de mise à jour d’ici là sur les 5 ou 6 appareils qui recevront Android 14
Windows 11 exige TPM et Secure Boot
J’ai entendu dire que certains pays en développement exigent l’installation d’une CA nationale afin de pouvoir intercepter toutes les connexions ; si cela devient très difficile, il devient concrètement plus difficile de pousser les utilisateurs à désactiver leur propre confidentialité
J’utilise un PinePhone Pro comme téléphone principal
Chase.com essaie vraiment avec insistance de bloquer les navigateurs non standard comme Librewolf, ainsi que les navigateurs sur téléphone/tablette, et de forcer l’usage de l’application mobile
Au moins jusqu’à ce que WEI devienne obligatoire, ces mesures stupides se contournent facilement, donc ce n’est pas un problème grave, mais comme Chase est une banque, je me demande s’il y aurait matière à contestation juridique
Ma première hypothèse serait la conformité à l’ADA, mais je n’en suis pas sûr
Je suis désormais tellement épuisé que je ne sais même plus si je plaisante quand je dis que j’aimerais intenter un procès à ce sujet
C’est un peu une digression, mais c’est lié, car cela montre une autre facette du fait qu’il est presque impossible de sortir de l’oligopole des OS mobiles
Même si la niche des téléphones Linux atteignait miraculeusement quelques pourcents, Android risque fort de continuer à se dégrader, et il faudra quelque chose
Je pense qu’une ère de servage numérique va arriver
On utilisera un appareil fourni par une entreprise « bienveillante », cette entreprise possédera tous les aspects de l’appareil, et il faudra payer pour l’utiliser comme on paie pour conduire
La plupart des autres voies seront verrouillées, l’informatique généraliste ne restera disponible que pour « l’entreprise », et il existera bien un « web libre », mais il sera assez technique et hostile à l’utilisateur
La majeure partie du marché, en particulier tout ce qui touche à l’argent, l’évitera comme la peste
À mon avis, Google a tué le web ouvert avec ça
De toute façon, il devenait un peu ennuyeux, mais il est agaçant de constater qu’il est maintenant beaucoup plus difficile de vivre sans téléphone ou sans navigateur « approuvé »
C’est bien qu’un utilisateur expérimenté sache installer des logiciels supplémentaires pour résoudre le problème, mais il vaudrait mieux que Chase corrige son site web de base afin que des utilisateurs débutants ayant des besoins similaires puissent aussi être aidés
Sur ce point, je pense qu’Android a été, et reste, plus coercitif qu’Apple
Même à l’époque où l’on pouvait installer une nouvelle AC racine et lui faire confiance, certaines apps pouvaient l’ignorer, et l’ignoraient effectivement
iOS comme Android permettent aux apps d’utiliser l’épinglage de certificat, mais depuis Android 7+, les apps ignorent par défaut, depuis 2016, les AC ajoutées par l’utilisateur[1]
Sur iOS, le processus pour faire confiance à une AC racine est pénible, avec installation d’un profil et avertissements inquiétants, ce qui se justifie en soi, mais d’après mon expérience la plupart des apps lui font confiance, sauf si elles utilisent l’épinglage de certificat
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
Android, qui est bien plus proche d’un ordinateur généraliste qu’iOS, a un très gros problème de stalkerware
Les stalkerwares ne sont pas arrêtés par des invites, instrumentalisent la compatibilité descendante et impliquent toutes sortes d’abus
Sur iOS, il est étonnamment facile de prêter son téléphone à quelqu’un cinq minutes puis de voir sa confidentialité HTTPS compromise pendant des années
Je veux disposer d’une option permettant de réellement faire confiance aux certificats d’AC installés, mais il est agaçant que même Firefox, pourtant un navigateur web, n’utilise pas les certificats utilisateur sans combinaison d’onglets cachée et réglages
Malgré tout, vu les risques pour les utilisateurs Android du monde entier, il est difficile de considérer que cette fonction est aussi importante pour quelques dizaines de techniciens qui l’utilisent au quotidien
Dans ce cas, je vois plutôt un effet de bord des bonnes améliorations de sandboxing de Google et du mécanisme longtemps attendu de mise à jour du magasin d’AC, plutôt qu’un complot maléfique de Google visant à contrarier les plans du service informatique local
Un module Magisk apparaîtra bientôt comme solution de contournement, et les modules existants casseront pendant un moment, mais c’est fréquent après une mise à jour majeure d’Android
Si nécessaire, on peut aussi écrire soi-même un module
J’ai l’impression que c’est simplement la façon dont fonctionnent les montages
Si quelque chose est monté sur
/apex/whateveret que chaque app possède un espace de noms de montage distinct, alors remonter quelque chose par-dessus/apex/whateverdans son propre espace de noms ne change rien dans les autres espaces de nomsIl faut soit modifier directement le système de fichiers, soit entrer dans l’espace de noms de montage de l’autre app et y monter aussi un tmpfs
Les montages partagés pourraient peut-être aider, mais je n’en suis pas sûr, et il faudrait examiner plus en détail ce qui se passe réellement
Je pense que ce résultat est plus probablement un sous-produit du travail de Google sur les espaces de noms et la conteneurisation qu’une tentative délibérée d’empêcher les utilisateurs de modifier les AC racines même avec les droits root
Mais le résultat final reste un gros problème
Ce qui est surprenant ici, c’est l’« espace de noms de montage distinct »
Avant, on ouvrait un shell et, si l’on montait quelque chose dans le système de fichiers ou qu’on le modifiait directement, les apps lisaient correctement les fichiers depuis ce montage
Désormais, ce n’est plus le cas pour ces fichiers cacert, et avec la nouvelle méthode, la modification directe est également impossible
Avant ce changement, je ne savais même pas que les apps Android utilisaient leur propre espace de noms de montage
Il existe très peu de documentation sur son fonctionnement exact, et je ne suis même pas sûr qu’un cas aussi clair soit apparu jusqu’à présent
Il suffit de regarder manifest v3
J’ai répondu à l’auteur sur Twitter, mais il ne l’a peut-être pas vu, donc je le laisse aussi ici.
Je suis la personne qui a écrit l’article de blog sur les certificats pouvant être mis à jour dans Android 14, et l’article est lié dans la news.
Il existe en fait une propriété système que l’on peut définir pour contourner la lecture depuis le répertoire des certificats APEX.
system.certs.enabled=trueSource : https://android-review.googlesource.com/c/platform/framework...
Ce n’est pas une propriété d’OS
android.os.SystemProperties, c’est-à-dire une valeur configurable globalement sur l’appareil viaadb, mais une propriétéjava.lang.System, autrement dit un paramètre de configuration défini au sein d’une JVM/appli.À mon avis, pour redéfinir la première, il faudrait modifier l’appli elle-même.
C’est utile pour les tests automatisés ou pour basculer un réglage entre builds debug/prod, mais ça n’aide pas vraiment quand on veut faire confiance à des certificats d’AC à l’échelle de tout l’appareil.
Bien sûr, si tu connais un moyen de définir ce genre de propriété depuis l’extérieur et de l’appliquer à toutes les applis, ça fonctionnerait très bien, donc je serais vraiment curieux de l’entendre.
Pour info, je suis l’auteur, et je ne vois pas cette réponse sur Twitter.
Bien digne de Twitter en 2023.
Ça semble bon pour la sécurité et infernal pour certains développeurs, mais je me demande ce qui se passera quand cette version d’Android sera abandonnée dans 2 ou 3 ans.
Faudra-t-il prier pour que les certificats codés en dur tiennent quelques années de plus ?
Android 14 rend les certificats racine actualisables via Google Play, et il n’est plus nécessaire de passer par une mise à jour OTA pour ajouter ou supprimer des certificats racine comme avant.
Il existe aussi une solution de contournement que j’ai découverte aujourd’hui [0].
Si vous utilisez Android 7.0 ou une version antérieure, il peut être nécessaire d’agir pour continuer à accéder aux sites web protégés par des certificats Let’s Encrypt ; il est recommandé d’installer et d’utiliser Firefox Mobile, qui utilise son propre magasin de confiance au lieu de celui de l’OS Android.
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
La mise à jour de Google ne contenait pas le certificat intermédiaire utilisé par Let’s Encrypt.
Ce n’est pas un problème hypothétique futur, c’est un problème qui existe dès maintenant.
Pourquoi Google devrait-il être l’arbitre final de qui je décide de faire confiance ?
Google a clairement aussi des failles.
Et parmi les fournisseurs de certificats déjà approuvés, certains ne devraient pas réellement être considérés comme fiables, car ils ont déjà délivré des certificats à des personnes et organisations qui n’auraient pas dû en avoir.
Les applis n’acceptent généralement pas les certificats utilisateur, et quand Google Cloud, ou quelque chose qui y est lié, est passé à des certificats plus récents, certaines applis ont commencé à ne plus fonctionner.
Autrement dit, ils sont mis à jour hors bande via Play Services et ne nécessitent pas de mise à jour de l’OS par l’OEM.
À chaque sortie d’Android, je vois quelque chose disparaître et des choses assez inutiles être ajoutées.
iOS semble aller dans le sens inverse, au point qu’ils pourraient lentement se rejoindre au milieu et qu’iOS pourrait ensuite dépasser Android sur tous les plans.
J’aimerais avoir l’avis franc de personnes côté Apple.
J’utilise macOS ces temps-ci, et je déteste le fait qu’il échoue sur des aspects très basiques de l’expérience utilisateur qui sont acquis depuis des décennies sur Windows/Linux.
Finder, par exemple, est vraiment catastrophique.
Si j’achète un iPhone au lieu d’un Android pour la prochaine génération, aurai-je la même réaction négative à iOS ?
Peut-on considérer que, pour les usages d’un smartphone, iOS offre une expérience utilisateur plus aboutie et plus utile que macOS ?
J’ai envie de basculer, mais je ne veux pas perdre du temps et de l’argent.
L’Android d’autrefois était plus qu’un iOS avec de simples
.apk, et c’est vraiment dommage.Pour ces usages, ça va.
Mais l’utilisateur y est tellement limité que, même si je pourrais envisager le jailbreak, j’essaie de minimiser mon usage du téléphone et de faire presque tout sur desktop.
Pour info, je suis aussi en train d’abandonner macOS pour passer à Linux.
J’utilise une PKI personnelle pour accéder à des logiciels auto-hébergés
Des choses comme un serveur e-mail, un fournisseur de calendrier, un serveur de notes, un outil de synchronisation de photos
Je devrais pouvoir ajouter mon certificat racine à la liste des autorités de certification
Je ne veux pas modifier la liste fournie par le système, seulement ajouter mon certificat
C’est mon appareil, donc j’estime que je devrais pouvoir y changer ce que je veux si je le souhaite
Les apps de mail et de calendrier en font très probablement partie
Ce qui a de grandes chances de ne pas fonctionner, c’est l’usage consistant à installer sa propre AC pour intercepter le trafic entre une app et les serveurs de son éditeur
C’est dommage, car on devrait pouvoir inspecter ce que fait son propre appareil, mais le cas d’usage d’une PKI privée pour des logiciels auto-hébergés est bel et bien pris en charge
Il doit bien y avoir une méthode
getlocalcert développe un outil pour ça [1]
Comme cela évite d’avoir à ajouter une racine de confiance, pour certains réseaux l’approche « certificats publics sur réseau privé » est globalement avantageuse
Honnêtement, je ne m’attendais pas à ce qu’Android bloque les AC privées, mais c’est bien ce qui est arrivé
[1] https://www.getlocalcert.net/
Je n’utilise pas de téléphone Android en ce moment, mais je me souviens qu’avant, on pouvait ajouter son propre certificat d’AC à un téléphone Android sans accès root, simplement via une option dans les paramètres, et qu’au moins des apps comme les navigateurs web lui faisaient confiance
Ce n’est pas non plus une histoire qui remonte à très loin
Je ne comprenais donc pas pourquoi l’installation d’un certificat personnalisé nécessitait de rooter l’appareil, ni s’il s’agissait d’un autre usage
HTTP Toolkit m’a été très utile pour extraire les API cachées de la pitoyable app turque de recharge de véhicules électriques
J’ai aussi utilisé Frida pour contourner le certificate pinning SSL et la détection du root
Puis j’ai compris que la raison pour laquelle ils essayaient de cacher ces API était peut-être que ces API étaient des monstruosités /s