Principes du chiffrement
HTTPS et le chiffrement des messages ne sont pas la même chose
La différence entre protéger une connexion et chiffrer un message avant qu’il ne quitte le navigateur.
Publié le: 29 mars 2026
Limites de l’implémentation actuelle
Le client actuel chiffre le texte dans le navigateur et place le contenu chiffré dans l’URL. Le mot de passe transmis séparément ne fait pas partie du lien. Aucun serveur applicatif ne stocke, ne récupère, ne supprime ou ne consomme les messages une seule fois.
Contexte complémentaire
Imaginez deux enveloppes.
La première circule dans un tunnel surveillé, est ouverte à destination, puis remise au personnel du bureau. Cela ressemble à HTTPS.
L’analogie est imparfaite. Les serveurs web ne sont pas des bureaux, TLS n’est pas un tunnel et JavaScript transforme volontiers les analogies simples en diagrammes d’architecture. La distinction reste toutefois utile.
Sans HTTPS, une personne située sur le chemin réseau peut éventuellement observer ou modifier le trafic.
Collogue doit utiliser HTTPS indépendamment de tout chiffrement supplémentaire des messages. La cryptographie côté navigateur fournie par une connexion non fiable pourrait être remplacée avant son exécution.
HTTPS protège le trajet. L’application de destination peut tout de même traiter le contenu.
La question de savoir si elle le fait relève d’une décision de l’application.
Avec le chiffrement côté navigateur, la page transforme le texte en clair en texte chiffré avant l’envoi de la requête de création.
Cela ne rend pas TLS facultatif. La connexion transporte toujours des identifiants, du texte chiffré, du code applicatif et des métadonnées opérationnelles. Un attaquant capable de modifier la page pourrait altérer le processus de chiffrement.
Une évaluation de sécurité utile considère au moins quatre états.
Le texte en clair existe dans le navigateur de l’expéditeur.
Les menaces comprennent les extensions malveillantes, les scripts, les logiciels malveillants, le regard d’une personne à proximité et les copier-coller accidentels.
La requête peut contenir du texte en clair ou du texte chiffré selon l’application.
Le texte en clair existe dans le navigateur du destinataire.
Le destinataire peut le lire, tout comme un logiciel suffisamment privilégié sur cet appareil.
Une affirmation de sécurité qui ne parle que d’un seul de ces états est incomplète.
- copier le texte en clair avant le chiffrement ;
- envoyer la clé à un autre point d’accès ;
- affaiblir la génération aléatoire ;
- remplacer un algorithme ;
- modifier le lien de destination.
Ce n’est pas un argument contre la cryptographie dans le navigateur. C’est un argument en faveur de modèles de menace précis, d’un déploiement sûr, de contrôles de sécurité du contenu, de la transparence du code source, de builds reproductibles lorsque cela est possible et d’examens indépendants.
Le chiffrement côté client peut créer une limite différente lorsque l’application ne reçoit jamais la clé du message.
Là encore, vérifiez Collogue au lieu de généraliser.
Quelqu’un sur le réseau peut-il lire ou modifier cette connexion sans difficulté ?
Sous quelle forme le message atteint-il l’application ?
Qui possède ce qui est nécessaire pour le déchiffrer ?
Pendant combien de temps et à quelle fréquence le service le renverra-t-il ?
Ces contrôles se complètent. Aucun ne doit s’attribuer le mérite des autres.
Non. HTTPS protège l’application fournie, les requêtes, les identifiants et le texte chiffré contre l’observation et la modification sur le réseau.
Oui. TLS est généralement terminé au niveau du service, après quoi l’application traite les valeurs transmises.