Le chiffrement de bout en bout est une couche supplémentaire, pas une permission d’ignorer les alertes TLS ou de faire confiance à du code altéré.
TLS et le chiffrement de bout en bout établissent deux frontières différentes. Ces frontières comptent aussi dans l’évaluation des VPN et des proxys. TLS protège généralement la connexion entre votre appareil et le service ; un chiffrement de bout en bout correct et authentifié protège le contenu de la conversation jusqu’à l’appareil du destinataire. Lire la couche TLS ne signifie pas nécessairement lire le contenu chiffré de bout en bout, mais cela ne permet pas de conclure que la sécurité de TLS n’a plus d’importance.
Si un intermédiaire peut terminer la connexion sécurisée, il peut éventuellement non seulement observer les données transmises, mais aussi modifier les réponses ou le code de l’application web. C’est pourquoi « contourner TLS avec LVR1 » ne décrit pas correctement la sécurité d’une messagerie.
Comment un certificat racine peut-il permettre une inspection ?
Lors d’une connexion HTTPS, l’appareil vérifie la chaîne de certificats du serveur et le nom d’hôte. Si un intermédiaire présente un certificat que l’application considère comme valide, il peut établir deux connexions distinctes : l’une avec l’utilisateur et l’autre avec le véritable serveur. Il est alors une extrémité de l’une des connexions TLS, et non un observateur qui aurait cassé le chiffrement simplement en regardant les paquets.
L’installation d’un certificat quelconque ne suffit pas à elle seule ; l’application doit lui faire confiance et les vérifications de la connexion doivent également réussir. La documentation Android sur la configuration de la sécurité réseau explique que les politiques de confiance peuvent varier d’une application à l’autre. Les applications ciblant Android 7.0 ou une version ultérieure ne font pas confiance par défaut aux certificats ajoutés par l’utilisateur, sauf configuration contraire.
Il s’agit d’un mécanisme technique général. Sans éléments probants, il ne permet aucune conclusion sur un opérateur, un pays ou un incident précis. Une perturbation ou un filtrage ne prouve pas à lui seul qu’une inspection TLS a réussi.
Que devient visible si TLS est ouvert ?
| Type de données ou situation | Conséquence possible d’une inspection TLS |
|---|---|
| Contenu protégé uniquement par HTTPS | Un intermédiaire de confiance peut éventuellement voir le texte en clair |
| Message déjà chiffré avec la clé valide du destinataire | L’intermédiaire rencontre généralement du texte chiffré, pas le texte du message |
| Données de routage, de session ou requêtes annexes | L’étendue de l’exposition dépend du format et de la conception du service |
| Code de la version web reçu par le même chemin | Une modification du code peut menacer la sécurité du terminal |
| Service indisponible ou trafic bloqué | Le chiffrement ne suffit pas à établir une connexion |
La protection du contenu par E2EE dépend aussi de l’authenticité de la clé du destinataire et de l’intégrité des logiciels des deux parties. Si un attaquant remplace la clé initiale ou altère l’application qui voit le message avant son chiffrement, la simple présence d’AES ou de ML-KEM ne suffit pas.
Pourquoi la version web a-t-elle besoin d’un TLS sûr ?
Une application web reçoit généralement son code exécutable du serveur. Si ce code est malveillant, il peut accéder au contenu avant le chiffrement ou après le déchiffrement. On ne peut évaluer le chiffrement de bout en bout indépendamment de la manière dont le code est livré et exécuté.
Pour une version installée, l’authenticité du paquet, les mises à jour et l’intégrité du système d’exploitation comptent aussi. Les signatures de paquet et les vérifications de hachage sont utiles, mais ne constituent pas un test complet de la sécurité de l’application. Le modèle de menace de Livara indique également que, si un attaquant modifie à la fois le fichier et le hachage affiché, la concordance du hachage ne suffit pas à prouver l’authenticité.
Que revendique Livara ?
Selon la documentation de sécurité de Livara, les messages directs utilisent LVR1 et les groupes privés compatibles utilisent LGS1. La documentation décrit la combinaison de P-256 et de ML-KEM-768 ainsi que le chiffrement du contenu des messages. Ce sont des affirmations du produit, et non les résultats d’un audit indépendant réalisé dans cet article.
La même page décrit aussi la conservation des métadonnées de routage et le caractère public des canaux de diffusion. La bonne conclusion n’est donc pas que « toutes les informations sont cachées » ou qu’« aucune confiance dans le réseau n’est nécessaire ». Il faut plutôt évaluer la protection du contenu privé séparément de la connexion, de la distribution des clés, du code de l’application et des métadonnées.
Que faire face à une alerte de certificat ?
- N’ignorez pas une alerte du navigateur ou de l’application pour poursuivre une conversation sensible.
- Vérifiez la date de l’appareil et l’adresse exacte du service ; toute erreur de certificat n’est pas nécessairement une attaque.
- Si l’appareil est géré par une organisation, interrogez l’administrateur autorisé sur les politiques de gestion et les certificats installés ; ne modifiez pas les paramètres gérés de votre propre initiative.
- N’installez pas un certificat ou un profil simplement parce qu’un message inconnu vous le demande.
- Pour les conversations sensibles, comparez les empreintes des clés avec votre interlocuteur par un canal indépendant ; la concordance des clés ne remplace pas la résolution d’une alerte TLS.
Questions fréquentes
Un VPN résout-il tous ces problèmes ?
Non. Un VPN peut modifier le chemin depuis lequel le trafic est observé, mais il ne corrige pas automatiquement un appareil infecté, un certificat de confiance malveillant ou du code web altéré.
Une authentification sans envoi de mot de passe suffit-elle ?
Non. Le protocole d’authentification, la gestion des sessions et le chiffrement des messages ont des fonctions différentes. Une fausse page de connexion ou du code malveillant peut récupérer la saisie de l’utilisateur avant même l’exécution du protocole.
Principe pratique : E2EE est une couche précieuse ; n’y voyez pas une permission d’ignorer les certificats, l’authenticité de l’application ou la vérification des clés.
