Correction de l'erreur de contexte sécurisé HTTPS de Vaultwarden avec un proxy inverse

Les utilisateurs auto-hébergeant Vaultwarden rencontrent souvent une erreur bloquante lors de l'accès au coffre-fort web via HTTP simple depuis une autre machine. L'application refuse de se charger, invoquant l'absence d'un contexte sécurisé requis pour les opérations cryptographiques. Ce problème découle des normes de sécurité des navigateurs plutôt que d'un bug logiciel, nécessitant un ajustement spécifique de l'infrastructure pour le résoudre.

Ce qui s'est passé

Lorsque les utilisateurs démarrent Vaultwarden avec une commande Docker basique qui mappe le port 8000 sur le port 80, ils peuvent accéder à l'interface localement via localhost. Cependant, tenter d'atteindre le service depuis un autre appareil sur le réseau local en utilisant une adresse IP entraîne un échec. Le navigateur affiche une erreur indiquant qu'un contexte sécurisé est requis pour que l'API Subtle Crypto fonctionne. Cela empêche la page de connexion de s'afficher correctement et bloque toute interaction ultérieure avec le gestionnaire de mots de passe.

La cause profonde réside dans la manière dont les navigateurs modernes gèrent les fonctions cryptographiques sensibles. Vaultwarden s'appuie sur l'API Web Crypto pour chiffrer et déchiffrer les données du coffre directement dans le navigateur. Les navigateurs restreignent l'accès à cette API aux contextes sécurisés, définis comme des pages servies via HTTPS ou depuis localhost. L'accès au service via une adresse IP locale sur HTTP ne constitue pas un contexte sécurisé, ce qui rend l'objet crypto.subtle indéfini et casse la fonctionnalité principale de l'application.

Pour corriger cela, l'approche recommandée consiste à placer un proxy inverse devant le conteneur Vaultwarden. Le guide démontre l'utilisation de Caddy, un serveur web connu pour ses capacités HTTPS automatiques. En configurant Caddy pour gérer la terminaison TLS et transmettre les requêtes à l'instance Vaultwarden, les utilisateurs peuvent établir le contexte sécurisé nécessaire. Cette configuration garantit que toutes les connexions clients, qu'elles proviennent de navigateurs de bureau ou d'applications mobiles, s'effectuent via HTTPS, satisfaisant ainsi tant les exigences de sécurité des navigateurs que les politiques des applications clientes.

Détails clés

• La version 1.37.4 de Vaultwarden a été utilisée dans l'environnement de test, exécutée sur Docker.
• L'erreur survient car crypto.subtle n'est pas disponible dans les contextes HTTP non sécurisés provenant d'IPs distantes.
• L'accès via localhost sur HTTP affiche la page mais échoue avec les clients Bitwarden modernes exigeant HTTPS.
• Caddy a été configuré avec tls internal pour les tests et reverse_proxy pour transférer le trafic.
• La variable d'environnement DOMAIN doit correspondre exactement à l'URL HTTPS utilisée par les clients.
• L'inscription ouverte doit être désactivée via SIGNUPS_ALLOWED=false après la création initiale du compte.

Contexte

Les contextes sécurisés sont une fonctionnalité fondamentale de la sécurité web qui protège les API sensibles contre leur exposition sur des connexions non sécurisées. L'API Subtle Crypto, utilisée pour des opérations de haute sécurité comme la génération de clés et le chiffrement, n'est accessible que dans ces contextes. Cette restriction prévient les attaques de type homme-du-milieu (man-in-the-middle) où un attaquant pourrait intercepter ou manipuler des clés cryptographiques transmises via HTTP simple. Pour les applications auto-hébergées comme Vaultwarden, qui traitent des données personnelles sensibles, cette application au niveau du navigateur garantit que le chiffrement s'effectue en toute sécurité côté client avant que les données n'atteignent le serveur.

Les proxies inverses agissent comme intermédiaires entre les clients et les services backend. Ils gèrent les requêtes entrantes, administrent les certificats SSL/TLS et transmettent le trafic vers le service interne approprié. L'utilisation d'un proxy inverse comme Caddy simplifie le déploiement d'HTTPS en automatisant la gestion des certificats. Au lieu de configurer TLS directement dans le conteneur de l'application, ce qui peut être complexe et sujet aux erreurs, le proxy gère la connexion sécurisée en externe. Cette architecture permet également au service backend d'écouter uniquement sur localhost, réduisant son exposition au réseau et améliorant la posture de sécurité globale.

Pourquoi c'est important

Pour les équipes et les individus qui font tourner leurs propres logiciels, comprendre la distinction entre l'accès local et l'accès réseau est crucial. Une configuration qui fonctionne parfaitement sur la machine hôte peut échouer complètement pour les autres utilisateurs du réseau si HTTPS n'est pas correctement configuré. Ce problème souligne l'importance de traiter les services auto-hébergés avec la même rigueur de sécurité que les applications publiques. Ignorer les exigences HTTPS peut entraîner des dysfonctionnements, surtout à mesure que les applications clientes deviennent plus strictes sur l'imposition de connexions sécurisées.

De plus, la dépendance à la cryptographie basée sur le navigateur signifie que l'infrastructure soutenant l'application doit garantir la sécurité du transport. Sans un certificat HTTPS valide, toute la proposition de valeur d'un gestionnaire de mots de passe à connaissance zéro est compromise, car le navigateur ne peut pas effectuer les étapes de chiffrement nécessaires. La mise en œuvre d'un proxy inverse ne corrige pas seulement l'erreur immédiate, mais établit également une base évolutive pour ajouter davantage de services à l'avenir, tous bénéficiant d'une gestion centralisée des certificats et de contrôles d'accès sécurisés.

Que pouvez-vous faire

• Déployez un proxy inverse comme Caddy ou Nginx devant votre conteneur Vaultwarden.
• Configurez le proxy pour servir HTTPS en utilisant un certificat valide, tel que Let's Encrypt pour les domaines publics.
• Liez Vaultwarden uniquement à 127.0.0.1, en veillant à ce qu'il ne soit pas directement accessible depuis le réseau.
• Définissez la variable d'environnement DOMAIN sur l'URL HTTPS exacte que les clients utiliseront pour se connecter.
• Désactivez les inscriptions ouvertes en définissant SIGNUPS_ALLOWED sur false après la création de votre compte administrateur.
• Vérifiez que les clients mobiles peuvent se connecter, en vous assurant que la chaîne de certificats est approuvée sur tous les appareils.