Behebung des Vaultwarden-Fehlers „HTTPS Secure Context“ mit einem Reverse Proxy

Selbst-Hoster, die Vaultwarden bereitstellen, stoßen häufig auf einen blockierenden Fehler, wenn sie über reines HTTP von einem anderen Rechner aus auf das Web-Vault zugreifen. Die Anwendung weigert sich zu laden und meldet einen fehlenden sicheren Kontext, der für kryptografische Operationen erforderlich ist. Dieses Problem resultiert aus Browser-Sicherheitsstandards und nicht aus einem Softwarefehler, weshalb eine spezifische Anpassung der Infrastruktur zur Lösung notwendig ist.

Was passiert ist

Wenn Benutzer Vaultwarden mit einem einfachen Docker-Befehl starten, der Port 8000 auf Port 80 mappt, können sie die Oberfläche lokal über localhost aufrufen. Der Versuch jedoch, den Dienst von einem anderen Gerät im lokalen Netzwerk über eine IP-Adresse zu erreichen, schlägt fehl. Der Browser zeigt eine Fehlermeldung an, dass ein sicherer Kontext für die Funktion der Subtle Crypto API erforderlich ist. Dies verhindert, dass die Login-Seite korrekt gerendert wird, und stoppt jede weitere Interaktion mit dem Passwortmanager.

Die Ursache liegt darin, wie moderne Browser sensible kryptografische Funktionen handhaben. Vaultwarden verlässt sich auf die Web Crypto API, um Vault-Daten direkt im Browser zu verschlüsseln und zu entschlüsseln. Browser schränken den Zugriff auf diese API auf sichere Kontexte ein, definiert als Seiten, die über HTTPS oder von localhost aus ausgeliefert werden. Der Zugriff auf den Dienst über eine lokale IP-Adresse via HTTP qualifiziert sich nicht als sicherer Kontext, wodurch das Objekt crypto.subtle undefiniert bleibt und die Kernfunktionalität der Anwendung beeinträchtigt wird.

Um dies zu beheben, wird empfohlen, einen Reverse Proxy vor den Vaultwarden-Container zu setzen. Diese Anleitung demonstriert die Verwendung von Caddy, einem Webserver, der für seine automatischen HTTPS-Funktionen bekannt ist. Durch die Konfiguration von Caddy zur TLS-Terminierung und zum Weiterleiten von Anfragen an die Vaultwarden-Instanz können Benutzer den erforderlichen sicheren Kontext herstellen. Dieses Setup stellt sicher, dass alle Client-Verbindungen, ob von Desktop-Browsern oder mobilen Apps, über HTTPS erfolgen und somit sowohl die Sicherheitsanforderungen des Browsers als auch die Richtlinien der Client-Anwendungen erfüllen.

Wichtige Details

• In der Testumgebung wurde Vaultwarden Version 1.37.4 verwendet, ausgeführt auf Docker.
• Der Fehler tritt auf, weil crypto.subtle in unsicheren HTTP-Kontexten von entfernten IPs nicht verfügbar ist.
• Der Zugriff über localhost via HTTP rendert die Seite zwar, scheitert aber bei modernen Bitwarden-Clients, die HTTPS erfordern.
• Caddy wurde für Tests mit tls internal konfiguriert und nutzt reverse_proxy, um den Traffic weiterzuleiten.
• Die Umgebungsvariable DOMAIN muss exakt der HTTPS-URL entsprechen, die von Clients verwendet wird.
• Die offene Registrierung sollte nach der initialen Kontoerstellung über SIGNUPS_ALLOWED=false deaktiviert werden.

Hintergrund

Sichere Kontexte sind ein grundlegendes Web-Sicherheitsmerkmal, das sensible APIs vor der Offenlegung über unsichere Verbindungen schützt. Die Subtle Crypto API, die für Hochsicherheitsoperationen wie Schlüsselgenerierung und Verschlüsselung genutzt wird, ist nur innerhalb dieser Kontexte zugänglich. Diese Einschränkung verhindert Man-in-the-Middle-Angriffe, bei denen ein Angreifer kryptografische Schlüssel abfangen oder manipulieren könnte, die über reines HTTP übertragen werden. Für selbst gehostete Anwendungen wie Vaultwarden, die sensible persönliche Daten verarbeiten, stellt diese browserseitige Durchsetzung sicher, dass die Verschlüsselung sicher auf der Client-Seite erfolgt, bevor Daten überhaupt den Server erreichen.

Reverse Proxies fungieren als Vermittler zwischen Clients und Backend-Diensten. Sie bearbeiten eingehende Anfragen, verwalten SSL/TLS-Zertifikate und leiten den Traffic an den entsprechenden internen Dienst weiter. Die Nutzung eines Reverse Proxys wie Caddy vereinfacht die Bereitstellung von HTTPS durch Automatisierung des Zertifikatsmanagements. Anstatt TLS direkt innerhalb des Anwendungscontainers zu konfigurieren, was komplex und fehleranfällig sein kann, übernimmt der Proxy die sichere Verbindung extern. Diese Architektur ermöglicht es zudem dem Backend-Dienst, nur auf localhost zu lauschen, was die Exposition gegenüber dem Netzwerk reduziert und die allgemeine Sicherheitslage verbessert.

Warum es wichtig ist

Für Teams und Einzelpersonen, die ihre eigene Software betreiben, ist das Verständnis der Unterscheidung zwischen lokalem und Netzwerkzugriff entscheidend. Ein Setup, das perfekt auf dem Host-Rechner funktioniert, kann für andere Nutzer im Netzwerk vollständig versagen, wenn HTTPS nicht korrekt konfiguriert ist. Dieses Problem unterstreicht die Bedeutung, selbst gehostete Dienste mit derselben Sicherheitsstrenge zu behandeln wie öffentlich zugängliche Anwendungen. Das Ignorieren von HTTPS-Anforderungen kann zu Funktionsstörungen führen, insbesondere da Client-Anwendungen strengere Anforderungen an sichere Verbindungen stellen.

Darüber hinaus bedeutet die Abhängigkeit von browserbasierter Kryptografie, dass die Infrastruktur, die die Anwendung unterstützt, Transportsicherheit garantieren muss. Ohne ein gültiges HTTPS-Zertifikat wird der gesamte Mehrwert eines Zero-Knowledge-Passwortmanagers kompromittiert, da der Browser die notwendigen Verschlüsselungsschritte nicht durchführen kann. Die Implementierung eines Reverse Proxys behebt nicht nur den unmittelbaren Fehler, sondern schafft auch eine skalierbare Grundlage für die zukünftige Hinzufügung weiterer Dienste, die alle vom zentralisierten Zertifikatsmanagement und sicheren Zugriffssteuerungen profitieren.

Was Sie tun können

• Stellen Sie einen Reverse Proxy wie Caddy oder Nginx vor Ihrem Vaultwarden-Container bereit.
• Konfigurieren Sie den Proxy so, dass er HTTPS mit einem gültigen Zertifikat ausliefert, beispielsweise Let's Encrypt für öffentliche Domains.
• Binden Sie Vaultwarden ausschließlich an 127.0.0.1, um sicherzustellen, dass es nicht direkt aus dem Netzwerk erreichbar ist.
• Setzen Sie die Umgebungsvariable DOMAIN auf die exakte HTTPS-URL, die Clients zur Verbindung verwenden.
• Deaktivieren Sie offene Registrierungen, indem Sie SIGNUPS_ALLOWED auf false setzen, nachdem Sie Ihr Admin-Konto erstellt haben.
• Überprüfen Sie, ob mobile Clients eine Verbindung herstellen können, und stellen Sie sicher, dass die Zertifikatskette auf allen Geräten vertrauenswürdig ist.