Sécurité et confidentialité

Hush Relay propose une messagerie chiffrée auto-hébergée expérimentale via PHP

Un nouveau projet open source permet des discussions privées et chiffrées de bout en bout à l'aide d'un seul fichier PHP et d'une application web, sans nécessiter de comptes ni d'infrastructure complexe.

Illustration d'un petit serveur et d'un appareil mobile représentant la messagerie chiffrée auto-hébergée
Illustration créée pour cet article

Traduit automatiquement depuis l’original en anglais.

Valentyn Rukhaylo a publié Hush Relay le 1er novembre 2026, un système de messagerie expérimental auto-hébergé conçu pour les utilisateurs soucieux de leur vie privée. Le projet combine une application web progressive (PWA) avec un serveur relais minimaliste en PHP, permettant aux particuliers de gérer leurs propres canaux de communication chiffrés sans dépendre de plateformes tierces ou de boutiques d'applications.

Ce qui s'est passé

Cette version introduit une alternative légère aux messageries grand public en éliminant les systèmes de comptes traditionnels et les infrastructures centralisées. L'application se compose de deux éléments principaux : une interface web côté client développée en HTML et JavaScript simples, et un serveur relais écrit sous la forme d'un unique fichier PHP. Cette architecture garantit que toutes les opérations cryptographiques s'effectuent dans le navigateur de l'utilisateur, tandis que le serveur ne sert que de support de stockage pour les paquets de données chiffrés.

Les utilisateurs peuvent déployer le relais sur du matériel très modeste, y compris un serveur privé virtuel (VPS) à 5 $, un Raspberry Pi, voire un téléphone Android inutilisé exécutant Termux. Le système prend en charge le déploiement sur des environnements d'hébergement mutualisé standard, le rendant accessible à ceux qui ne disposent pas de ressources DevOps dédiées. Le développeur souligne que cet outil est destiné à des fins de confidentialité quotidienne et pédagogiques plutôt qu'à des scénarios à haut risque impliquant des adversaires étatiques.

Détails clés

  • Relais à connaissance nulle : Le backend PHP stocke les messages chiffrés mais ne peut ni lire leur contenu ni identifier l'expéditeur grâce aux techniques d'expéditeur scellé (sealed sender).
  • Aucun compte requis : L'identité est dérivée de clés cryptographiques générées localement, éliminant le besoin d'enregistrement par numéro de téléphone ou adresse e-mail.
  • Secret forward : Le protocole implémente l'algorithme Double Ratchet, garantissant que les appareils compromis ne peuvent pas déchiffrer les messages capturés précédemment.
  • Migration entre appareils : Les utilisateurs peuvent transférer leur identité vers un nouvel appareil en scannant un code QR et en vérifiant un numéro de sécurité à 12 chiffres.
  • Relais interopérables : Différents utilisateurs peuvent exploiter leurs propres relais dans différentes juridictions, et ces relais peuvent communiquer entre eux.
  • Statut expérimental : Le code a fait l'objet d'une revue interne par des adversaires, mais manque d'un audit indépendant par des cryptographes externes.

Contexte

Le chiffrement de bout en bout garantit que seuls les utilisateurs communiquant peuvent lire les messages, empêchant les intermédiaires d'accéder au contenu. Hush Relay utilise les API WebCrypto dans le navigateur pour effectuer ces tâches cryptographiques lourdes, une approche standard pour les outils de sécurité web modernes. L'algorithme « Double Ratchet » mentionné dans la documentation est un protocole cryptographique bien connu utilisé par Signal et d'autres messageries sécurisées pour assurer le secret forward. Cela signifie que si un attaquant vole une clé de session, il ne peut pas l'utiliser pour déchiffrer les messages passés, car les clés évoluent à chaque échange.

Le concept de « relais stupide » est central dans cette conception. Dans les applications de messagerie traditionnelles, le serveur gère souvent les identités des utilisateurs, les listes de contacts et la logique de routage des messages. Dans Hush Relay, le serveur conserve simplement des blocs de données chiffrés jusqu'à ce que le destinataire les récupère. Cela réduit considérablement la surface d'attaque, car l'opérateur du serveur n'a aucune visibilité sur qui parle à qui, au-delà des métadonnées de base telles que les adresses IP et le moment des messages. L'utilisation de PHP, un langage serveur largement supporté, permet d'exécuter cela sur presque tout plan d'hébergement web existant sans conteneurisation spécialisée ni configuration de base de données.

Pourquoi c'est important

Pour les équipes et les individus qui auto-hébergent leurs logiciels, le contrôle de l'infrastructure de communication devient une priorité croissante. De nombreuses organisations sont méfiantes vis-à-vis des plateformes de messagerie propriétaires qui pourraient modifier leurs conditions d'utilisation, subir des pannes ou faire face à des pressions réglementaires pour transmettre des données. Hush Relay offre un moyen de maintenir des canaux de communication privés en utilisant une infrastructure que l'équipe contrôle déjà. Comme il fonctionne sur un hébergement mutualisé standard ou des instances VPS à faible coût, la barrière à l'entrée est remarquablement basse par rapport à la construction d'une solution de chat personnalisée depuis zéro.

Cependant, la nature expérimentale du projet nécessite une réflexion prudente. Le développeur avertit explicitement contre l'utilisation de cet outil dans des situations critiques où la sécurité physique ou la protection juridique sont en jeu. Sans audit de sécurité indépendant, il peut exister des vulnérabilités non découvertes dans l'implémentation des primitives cryptographiques ou de l'interface web. Pour les responsables IT, cela présente un compromis : le bénéfice d'une souveraineté totale des données contre le risque d'utiliser un logiciel de sécurité non audité. Il convient bien aux chats internes d'équipe ou aux conversations privées occasionnelles, mais pas à la protection de la propriété intellectuelle sensible ou des communications de lanceurs d'alerte.

Ce que vous pouvez faire

  • Tester localement : Clonez le dépôt et exécutez le script serve inclus pour tester l'interface sur votre machine locale en utilisant deux fenêtres de navigateur.
  • Déployer sur un hébergement existant : Si vous disposez d'un plan d'hébergement mutualisé basé sur cPanel ou Apache, téléversez le dossier web pour essayer le relais sans gérer un serveur.
  • Vérifier les contacts : Comparez toujours les numéros de sécurité avec vos contacts via un canal séparé pour prévenir les attaques de type homme du milieu (man-in-the-middle).
  • Sauvegarder les mots de récupération : Notez la phrase de récupération de six mots fournie lors de la configuration, car c'est le seul moyen de restaurer l'accès si vous perdez votre appareil.
  • Suivre les mises à jour : Suivez le dépôt pour les correctifs de sécurité, car le projet est marqué comme expérimental et susceptible de subir des changements rapides.
  • Évaluer les risques : N'utilisez pas cet outil pour des communications dont l'échec pourrait entraîner des préjudices personnels ou professionnels graves.

Autres actualités

Toutes les actualités