Ce que le certificate pinning bloque encore

Sur iOS, le déchiffrement dépend de l'installation du profil Busymate et de sa confiance totale dans les Réglages — ensuite, chaque app du téléphone fait confiance au certificat présenté par l'app, sauf celles qui épinglent. Sur Android il y a deux magasins : celui de l'utilisateur, que seules les apps ayant explicitement opté honorent depuis Android 7.0, et celui du système, que toutes les apps honorent mais que seul un appareil rooté peut modifier. Le proxy de bureau utilise la confiance que la machine ou le navigateur client accorde à son autorité générée.

Le pinning se situe au-dessus des trois. Une app qui épingle rejette le certificat de substitution quel que soit le magasin dont il vient, donc déplacer un certificat vers un magasin plus fort n'aide jamais contre un hôte épinglé. Cela n'aide que contre les apps qui refusaient le magasin utilisateur.

Un hôte que vous n'avez pas listé pour le déchiffrement affiche un cadenas fermé avec seulement le nom d'hôte et un compteur de requêtes — c'est voulu, pas du pinning. Un hôte épinglé a une autre allure : il est dans votre liste, le déchiffrement a été tenté, et la connexion a échoué ou l'app a réessayé puis abandonné. Le filtre d'inspection du flux du dashboard a trois réglages — déchiffrés seulement, chiffrés seulement, et SSL épinglés seulement — et le dernier isole exactement ces lignes.

L'autre indice est comportemental : l'app cesse de fonctionner pour cet hôte dès qu'il est déchiffré, et refonctionne dès que vous retirez l'hôte de la liste. Si les deux sont vrais, vous avez trouvé une connexion épinglée.

L'app iOS capture à l'échelle du système, en Wi-Fi comme en cellulaire, et déchiffre les hôtes que vous listez. Face à une app épinglée, elle enregistre toujours chaque connexion — l'hôte, le timing, le nombre et la taille des requêtes, le mode de connexion en vigueur — mais elle ne peut produire ni les en-têtes ni le corps, et aucun interrupteur ne change cela. Activer MITM All Hosts déchiffre tous les hôtes non épinglés ; sur un hôte épinglé, cela ne fait rien d'autre que le casser.

Le geste pratique consiste à retirer l'hôte épinglé de la liste pour que l'app continue de fonctionner, à y garder les autres hôtes de l'app, et à lire ce que révèlent les endpoints non épinglés. Beaucoup d'apps n'épinglent que leur hôte d'authentification ou de paiement et laissent le reste ouvert.

Sur un téléphone Android non rooté, le certificat généré par l'app vit dans le magasin utilisateur, donc seuls vos propres builds de debug et les autres clients ayant opté se déchiffrent ; toutes les autres apps sont enregistrées en métadonnées. Sur un appareil rooté, le certificat peut être installé dans le magasin système, et le HTTPS devient déchiffrable à l'échelle du système — sauf le pinning propre à chaque app. La ferme de téléphones fait tourner ses appareils Android à ce niveau rooté précisément pour cela.

Le root convertit donc une classe d'apps opaques en apps lisibles — celles qui ignoraient simplement le magasin utilisateur — et laisse la classe épinglée intacte. Busymate ne prétend jamais déchiffrer à l'échelle du système sur un appareil non rooté, ni vaincre le pinning sur un appareil rooté.

Le proxy de bureau entretient la même relation avec le pinning que les apps mobiles : un client épinglé refuse son certificat généré et la connexion échoue. Il porte aussi une courte liste d'hôtes qu'il n'intercepte jamais, quoi que disent vos réglages SSL proxy — la PKI et les endpoints de révocation d'Apple, les répondeurs de statut de certificat utilisés par la chaîne d'Apple, et le backend de Busymate lui-même — parce que les intercepter casserait l'appareil ou la connexion en direct du dashboard. Ils passent en tunnels bruts, et c'est intentionnel, pas une mauvaise configuration.

Il existe une voie de capture où le pinning est hors sujet. Le connecteur en ligne de commande lance une instance de Chrome et lit son trafic via le DevTools Protocol, du côté navigateur du TLS. La connexion chiffrée entre Chrome et le serveur n'est jamais touchée — pas de certificat de substitution à rejeter, rien à installer, rien que le pinning puisse détecter. Les flux de connexion chez des fournisseurs dont un proxy ne peut ouvrir les certificats épinglés sont enregistrés de bout en bout, redirections et jetons compris.

La contrepartie est la portée : il couvre ce qui tourne dans ce Chrome, pas une app native. Si le flux qui vous intéresse a une version web, c'est la voie qui le voit intégralement.

Les métadonnées ne sont pas rien. Vous voyez toujours quand l'app parle à l'hôte épinglé, à quelle fréquence, la taille des échanges et leur durée, et vous pouvez corréler cela avec les appels déchiffrés autour. Les règles de blocage correspondent toujours au niveau de l'hôte sur un hôte chiffré — le chemin est invisible, mais vous pouvez faire se comporter l'app comme si cet endpoint était injoignable, ce qui est souvent exactement le mode de défaillance que vous vouliez tester. Les pauses laissent l'hôte contourner entièrement le proxy pour que l'app continue de fonctionner pendant que vous inspectez tout le reste.

Et chaque action que vous avez faite figure dans la piste d'audit, si bien qu'une session de recherche laisse une trace de ce qui a été déchiffré, bloqué ou laissé tranquille.