Android 17 : ce que l’ECH chiffre réellement — et ce qu’il laisse visible

La principale évolution d’Android 17 en matière de confidentialité réseau s’appelle Encrypted Client Hello, ou ECH. Cette extension de TLS 1.3 chiffre le nom d’hôte normalement visible au début d’une connexion sécurisée. Les opérateurs Wi-Fi, les fournisseurs d’accès à Internet et d’autres observateurs du réseau auront ainsi plus de mal à déterminer précisément quel site ou service une application contacte. Mais l’ECH ne rend pas la navigation anonyme pour autant. 46

Pour fonctionner, la protection doit être prise en charge de bout en bout : le téléphone doit utiliser Android 17 ou une version ultérieure, l’application doit s’appuyer sur une bibliothèque réseau compatible et le service distant doit avoir déployé l’ECH. 25

Ce que l’ECH chiffre

Lors d’une connexion TLS classique, le client envoie une extension appelée Server Name Indication (SNI). Elle contient le nom d’hôte du service auquel il souhaite se connecter. L’ECH chiffre cette partie sensible du premier message ClientHello à l’aide d’une configuration et de clés publiées par le service distant. Le serveur peut ensuite déchiffrer les informations protégées, tandis qu’un observateur du réseau ne voit qu’une négociation externe, et non le nom d’hôte réellement demandé. 416

Cette nuance est importante : HTTPS chiffre déjà le contenu des échanges, mais le nom du service contacté peut encore révéler beaucoup de choses sur l’activité d’une application. L’ECH vise précisément à limiter cette fuite de métadonnées pour les destinations compatibles. 56

Les informations qui restent visibles

L’ECH ne chiffre pas tous les éléments d’une connexion. Selon l’emplacement de l’observateur et la configuration utilisée, celui-ci peut encore voir :

• l’adresse IP source de l’appareil ;
• l’adresse IP de destination, qui peut désigner un hébergeur, un réseau de diffusion de contenu (CDN) ou parfois un service précis ;
• les horaires de connexion, la taille des paquets et le volume de données échangé ;
• les requêtes DNS, si elles ne sont pas protégées séparément.

Il serait donc inexact de présenter l’ECH comme un VPN ou un système d’anonymat. Google décrit l’ECH et le DNS privé comme deux protections complémentaires : l’ECH masque le nom d’hôte dans la négociation TLS, tandis que le DNS chiffré protège l’étape distincte qui associe un nom de domaine à une adresse IP. Aucune de ces deux fonctions ne masque à elle seule l’adresse IP de l’appareil. 612

Les conditions requises et les réglages d’Android 17

Android 17 fournit le support du système et les API nécessaires aux bibliothèques réseau pour mettre en œuvre l’ECH. Cela inclut notamment des capacités de DnsResolver permettant de récupérer les enregistrements DNS HTTPS contenant les configurations ECH. 4

La protection effective dépend toutefois de trois conditions :

1. L’appareil doit fonctionner sous Android 17 ou une version ultérieure.
2. La pile réseau de l’application doit prendre en charge l’ECH. La documentation Android cite notamment HttpEngine, WebView et OkHttp, mais le support du système ne rend pas automatiquement toutes les bibliothèques compatibles. 23
3. Le serveur distant doit avoir déployé l’ECH. Sans configuration côté serveur, le client ne peut pas chiffrer le nom d’hôte demandé. 25

Pour les applications ciblant Android 17 ou une version ultérieure, l’ECH est utilisé pour les connexions TLS lorsque la bibliothèque réseau et le serveur distant prennent tous deux en charge le protocole. Si l’ECH ne peut pas être activé, la politique de chiffrement des domaines définie par l’application détermine si la connexion peut continuer ou si elle doit échouer de manière sécurisée. 12

À quoi sert l’ECH GREASE ?

La politique de chiffrement des domaines d’Android ne se résume pas à un simple bouton « activé » ou « désactivé ». Lorsque le chiffrement des domaines est activé mais que le serveur ne prend pas en charge l’ECH réel, Android peut envoyer à la place un ECH GREASE. Cette extension est volontairement non fonctionnelle, mais elle ressemble à un trafic ECH authentique.

L’objectif est double : favoriser la compatibilité et compliquer la classification rudimentaire du trafic. Un réseau ne devrait pas pouvoir déduire, à partir de l’absence d’une connexion ECH utilisable, que le client n’essaie jamais d’utiliser ce protocole. Le GREASE ne masque toutefois pas le nom d’hôte comme le ferait un ECH réussi : il s’agit d’un mécanisme de compatibilité, pas d’un substitut au déploiement côté serveur. 1

Si une application désactive le chiffrement des domaines, la documentation de NetworkSecurityPolicy précise que ni l’ECH ni le GREASE ne doivent être utilisés. L’API propose également plusieurs modes, dont un mode activé et un mode obligatoire. Dans ce dernier cas, la connexion doit échouer si l’ECH ne peut pas être établi. 1

Ce que les développeurs doivent faire

Le support intégré à Android 17 ne protège pas automatiquement le trafic de toutes les applications. Les développeurs doivent notamment :

• vérifier que la bibliothèque réseau utilisée par l’application a intégré la prise en charge de l’ECH ; 235
• configurer le fichier Network Security Config, ou la politique équivalente de chiffrement des domaines ; 15
• s’assurer que la bibliothèque peut récupérer et utiliser la configuration ECH publiée par le service distant ; Android fournit les API nécessaires pour obtenir les enregistrements DNS HTTPS correspondants ; 4
• tester le comportement avec des serveurs compatibles et incompatibles, notamment pour déterminer si l’application autorise une solution de repli ou exige l’ECH et bloque la connexion en cas d’échec. 1

Les exploitants de services doivent également déployer l’ECH et publier la configuration dont les clients ont besoin. Cette dépendance côté serveur explique pourquoi le support d’Android 17 ne masquera pas immédiatement le nom de tous les domaines consultés par toutes les applications. 516

Google indique travailler avec Jigsaw, des acteurs du secteur, des fournisseurs de services et des développeurs d’applications pour accélérer l’adoption. L’objectif est de rendre la protection du nom d’hôte accessible aux applications via des infrastructures réseau courantes, et pas uniquement à quelques navigateurs spécialement configurés. 46

Les autres protections réseau d’Android 17

L’accès au réseau local passe par une permission

Les applications ciblant Android 17 ou une version ultérieure doivent demander la permission d’exécution ACCESS_LOCAL_NETWORK avant de découvrir des appareils sur le réseau local ou de s’y connecter. Cette permission appartient au groupe existant NEARBY_DEVICES (« appareils à proximité »). Les utilisateurs ayant déjà accordé une autre permission de ce groupe peuvent donc ne pas voir apparaître une nouvelle demande au niveau du groupe. 217

Cette évolution vise à limiter les analyses silencieuses du réseau local, qui peuvent servir au suivi des utilisateurs, à la prise d’empreinte numérique ou à la détection d’appareils vulnérables. Les applications légitimes qui se connectent à des équipements domotiques, à des appareils de diffusion ou à d’autres appareils du réseau local doivent déclarer et demander cette permission. 1719

La Certificate Transparency est activée par défaut

Android 17 active par défaut la Certificate Transparency (CT) pour les connexions TLS. Cette technologie contribue à détecter les certificats publics délivrés à tort en exigeant leur présence dans des journaux publics et vérifiables. Les applications peuvent désactiver cette fonction globalement ou pour certains domaines via leur configuration de sécurité réseau. 3

Les opérateurs peuvent limiter la 2G

Android 17 ajoute également une protection contre les risques liés à la faible sécurité des réseaux mobiles 2G. Lorsque la compatibilité de l’appareil et de l’opérateur le permet, les opérateurs peuvent restreindre ou désactiver par défaut les connexions 2G. Cela réduit l’exposition aux fausses antennes-relais et aux attaques par SMS malveillants, parfois appelées « SMS blaster ». Le comportement exact dépend toutefois de l’opérateur et de l’appareil. 8

Le verdict sur la confidentialité

L’ECH constitue une amélioration concrète : lorsque le client et le serveur prennent en charge la norme, il retire le nom d’hôte d’une partie essentielle de la négociation TLS. Mais il ne rend pas la navigation invisible. Les requêtes DNS, les adresses IP de destination, les horaires, la taille des paquets et le volume du trafic peuvent encore fournir des indices.

Pour renforcer la confidentialité des domaines, l’ECH doit être associé à un DNS chiffré. Pour empêcher l’identification par l’adresse IP, il faut un outil distinct, comme un VPN, un proxy ou Tor.

La formulation la plus juste est donc la suivante : Android 17 rend les noms des sites et des services plus difficiles à lire pour les observateurs du réseau, mais laisse d’autres niveaux de métadonnées en dehors de la protection de l’ECH.