In this article we dig a little bit deeper into the hosting of Bitwarden. One interesting discovery is that the official Bitwarden web app under vault.bitwarden.com is hosted behind a Cloudflare proxy.

Before we dig into why or why not hosting a password manager like Bitwarden behind a service like Cloudflare’s proxy is problematic we will take inventory and check if Bitwarden really is behind Cloudflare and why that is the case.

Bitwarden and Cloudflare

The following commands show you that the DNS of the subdomain vault.bitwarden.com, from where your Bitwarden vault is accessed, is indeed behind Cloudflare. Making Cloudflare the man-in-the-middle per design.

$ dig +short vault.bitwarden.com
104.18.13.33
104.18.12.33

$ whois 104.18.13.33
[...]
OrgName:        Cloudflare, Inc.
OrgId:          CLOUD14
Address:        101 Townsend Street
City:           San Francisco
StateProv:      CA
PostalCode:     94107
Country:        US
[...]

In order for Cloudflare to offer their performance and security products, such as DDoS protection, the TLS connection is terminated at Cloudflare and a new TLS connection is opened to Bitwarden’s servers. Practically that means Cloudflare sees everything you send to Bitwarden and Bitwarden sends to you. The picture below is directly from the Cloudflare dashboard and visualizes those connections (taken from one of my own deployments).

Why does Bitwarden use Cloudflare?

Cloudflare provides multiple very useful services to protect Bitwarden’s infrastructure and improve their performance. To be fair Cloudflare is used by a lot of companies and is the de-facto market leader for CDNs and DDoS protection. The reasoning and why that is not such a big problem is outlined by a Bitwarden employee in the forum post Remove Cloudflare Proxy. The specific comment is shown in the screenshot below, but it is recommended to read the full thread to get a better understanding about the situation.

Why does it matter?

Having a third party as a man-in-the-middle in something so sensitive as a password manager is always critical, especially if this third-party sees the same data as Bitwarden sees.

As terrible as it sounds according to the Bitwarden documentation everything sensitive is encrypted locally on your device before sending it over the wire (end-to-end encryption), see Encryption.

How secure it that setup really?

In 99.9% of the cases the fact that everything is locally encrypted and all the other layers of security around it may be sufficient, but it definitely opens Bitwarden up to different attack vectors. For example a malicious insider at Cloudflare could inject or manipulate code send from Bitwarden to your device to name only one.

As outlined in the previous article Self Hosting Vaultwarden aka Bitwarden I self-host a Vaultwarden instance without any public exposure and no Cloudflare. To be fair I am self-hosting a second instance that is behind a Cloudflare proxy, but only is used for temporary secure data sharing via Bitwarden Send. For this instance Cloudflare is used for the all the same reasons Bitwarden uses them.

Verdict

For most people, especially non technical folks, the deployment architecture of Bitwarden may be completely fine. Self-hosting your instance without Cloudflare doesn’t make it automatically more secure. Keep in mind that you (most likely) don’t have a full 24/7 security team on staff and there is more to securing your password manager. Bitwarden also optimizes for different attack vectors, where Cloudflare has a place.

In the end it is important to understand what and why you are compromising and what attack vectors are relevant in your specific use case.