Hidden Services

Feature Requests Password Manager
1

Feature: Bitwarden Onion and I2p server URL for users who want better anonymity.

1 Like
2

Related/opposite of Restrict account access to certain countries/IP ranges / Restrict access from TOR.

I would like to opt-in to allow Tor/onion access to my account in case I needed to use Tails and an onion service would suggest that you aren’t opposed to Tor usage.

Do I understand correctly from these three issues that you allow logging in from Tor? As Bitwarden is a sensitive service, I was worried that by attempting to do that you might lock my account like banks are said to do for suspicious activity.

3

Disclaimer
I would like to contribute to this technical discussion, I hope to make an interesting view for most people. But I do not work for Bitwarden and have no connection with the company. In my case, I’m a Bitwarden user and would like to contribute with some ideas.

These ideas are not intended to endorse any position of the company or mine, they are just concepts about the feedbacks I read here. I am not a lawyer, judge, prosecutor, law student. So this text can be corrected or improved or improved by those who understand this subject. So if something is confusing or bad, look for your lawyer.

You all can agree or disagree with all or some points of view here, but leave your comment and opinion. I would be happy to hear all positive and negative opinions about these views.

I could be wrong, so don’t take all these views too seriously. I think we should add or think of more points of view. Before this feature is implemented or not.

Ideas

1. It would be interesting to include other network protocols like ‘dat’, ‘hypercore’, ‘ipfs’ etc. For example, in addition to the site in onion, solid-project, nostr, activityPub or i2p etc. It would be interesting to include decentralized storage, that is, instead of me storing my passwords in Microsoft Azure, I could tell Bitwarden to distribute my database of passwords on different servers, so that only I have access to a specific and exclusive key. This is similar to what the open source Anytype.io tool does to manage versioning via a random key. Also, there are requests to decentralize passwords on Bitwarden like these ones: Option to use P2P filesystem instead of server (IPFS), Offline Vault (P2P) or Require NFT for Login Option

2. For greater anonymity I think Bitwarden should include versions of the Bitwarden website and Bitwarden Login in things like: i2p, onion, nostr, freenet etc. This would be complex to maintain, manage with different types of users. But in the long term, this is interesting because it diversifies the portfolio of users who are more experienced in the area of information security and use some of these network protocols to send or receive information that is often confidential inside Bitwarden. In general, as there is no way to know the origin of the network that accessed the Bitwarden login, there would be greater digital security for any user and person using Bitwarden as a login.

3. I would like to highlight another interesting observation here. I would be happy as a user if there was an option for Bitwarden to offer password data sync options on things like protondrive, Tresorit or even offline as a Keepass plugin locally via jsonrpc or ajax calls. For even more strict users with digital security, local networks are generally more secure and restricted. Despite being susceptible to different attacks such as phishing, social engineering as common outside as within these types of communication network.

Onion address for Bitwarden?
Private key management for nostr accounts
4

I thought much the same. After all, secure services such as Proton Mail have an onion address.

HOWEVER, Proton Mail runs their own TOR exit node! Would Bitwarden be willing to run their own TOR exit node?

If not, then using TOR to access Bitwarden would post a significant security risk.

Introduction: I’ve been designing, configuring and using information and networking security since the mid-1980s. I’ve written for leading IT publications around the world. Here’s my 2 cents:

Yes, Bitwarden’s implementation of TLS is correct. Thus, when you access Bitwarden over a normal Internet connection, Bitwarden and your browser establish a secure Internet connection between them.

Or do they?

Yes, they do, but man-in-the-middle and evil twin attacks can represent each side to the other while standing in the middle and recording all information, which is WHY you should NEVER use WiFi, whether it’s in the airport, a coffee shop, or even your own, without a good VPN.

Even so, when you access Bitwarden over the regular Internet, you’re hidden in a sea of others.

Here’s the security issue with TOR: The last node in TOR, the “exit node,” applies the first layer of TOR encryption. As such, it also decrypts the final layer of TOR encryption and has access to your data stream, unencrypted by TOR, but still encrypted by TLS.

If the TOR network remains completely secure, then it does indeed secure and anonymize your traffic from your computer to the last node in the TOR network. Even so, bad actors can listen in on TOR exit node traffic, so you’ve highlighted yourself simply by using TOR.

Furthermore, the Internet is alive with reports of various government intelligence agencies and bad actors establishing TOR nodes. If one of their TOR nodes happens to be the final TOR node, then what’s to prevent them from conducting man-in-the-middle or evil twin attacks, thereby stealing your Bitwarden login credentials?

Well, nothing. This is WHY Proton Mail runs its own TOR exit node, and that’s the only way I ever access Proton Mail, along with a VPN and a third-party DNS SEC provider to maximize Zero Trust.

Recap:

  1. Yes, Bitwarden should indeed run their own TOR exit node.
  2. Users should always use a good VPN installed on their computing devices.
  3. Users should always use a good security suite, or at the very least, a good anti-virus/malware program.

The VPN secures your data stream before it ever leaves your computer. TOR adds additional layers of security and anonymity. Using a company’s own TOR exit node in conjunction with your VPN ensures mitigates the likelihood of any successful man in the middle or evil twin attacks.

5

Instead of shotgunning a large number of technologies, some of which are better than others, let’s keep it simple:

Recap:

  1. Yes, Bitwarden should indeed run their own TOR exit node.
  2. Users should always use a good VPN installed on their computing devices.
  3. Users should always use a good security suite, or at the very least, a good anti-virus/malware program.
6

Onion services without a dedication TOR exit node aren’t as secure as people imagine, and their use can indeed highlight you for unwanted targeting.

Recap:

  1. Yes, Bitwarden should indeed run their own TOR exit node.
  2. Users should always use a good VPN installed on their computing devices.
  3. Users should always use a good security suite, or at the very least, a good anti-virus/malware program.
7

@ace Are you sure you mean an exit node and not hidden service? In TOR, an exit node is to route traffic to the regular internet, which comes with significant legal risks, and is also unrelated to providing access to Bitwarden. If Bitwarden were available as a hidden service, the traffic would never go through any exit node.

Also, Protonmail does not advertise running an exit-node. They do advertise their hidden service.

Further, going through the previous message:

Yes, they do, but man-in-the-middle and evil twin attacks can represent each side to the other while standing in the middle and recording all information, which is WHY you should NEVER use WiFi, whether it’s in the airport, a coffee shop, or even your own, without a good VPN.

This is not true, unless the attacker has found a yet unknown cryptographic vulnerability in TLS, or has control over one of the root certificates in your device. The entire point of TLS is to prevent man in the middle attacks.

Here’s the security issue with TOR: The last node in TOR, the “exit node,” applies the first layer of TOR encryption. As such, it also decrypts the final layer of TOR encryption and has access to your data stream, unencrypted by TOR, but still encrypted by TLS.

There are 2 scenarios for TOR, accessing the wider internet, and accessing a hidden service. In either case the encryption is always applied on your device in layers, and the first node (entry guard) decrypts the outer layer, the second node the middle layer and so on.

In the case of accessing the internet, the exit node is the last node before accessing the regular internet over http/https.

In the case of a hidden service, NO EXIT NODE IS INVOLVED. Instead, both sides, the client and the hidden service establish their own connection to a rendevouz point, and the tor circuits get connected. Again, unless there is a cryptographic or implementation flaw found there is no way to man in the middle this.

Furthermore, the Internet is alive with reports of various government intelligence agencies and bad actors establishing TOR nodes. If one of their TOR nodes happens to be the final TOR node, then what’s to prevent them from conducting man-in-the-middle or evil twin attacks, thereby stealing your Bitwarden login credentials?

TLS already prevents this sufficiently. If your threat-model really is “government intelligence agencies” specifically targeting you, then you should not use a cloud service to store your passwords. From simple passive sniffing, TLS protects you.

To be clear, the advantage of Bitwarden running a hidden service would be that a user could explicitly allow Tor access in their settings via the hidden service. The regular vault.bitwarden.com site will most likely block tor exit nodes either way due to the amount of malicious traffic coming from them.

8

Agree @Quexten .

@ace I think you might be conflating a few different scenarios.

That said, I would like to contribute a focused PR for self-hosted (and potentially cloud hosted if you guys wanted it) .onion support.

The scope I am proposing is narrower than Bitwarden operating its own onion service. The goal would be to allow users who self-host Bitwarden to configure their server URL as an onion service address, for example:

http://<v3-onion-address>.onion

From the related “Permit http on iOS” thread, one blocker is that Bitwarden clients require server URLs to HTTPS, which does not work cleanly for HTTP onion services. There will also be changes needed to the clients.

Proposed self-hosted .onion setup

[Bitwarden Client]
        |
        | Custom server URL:
        | http://<v3-onion-address>.onion
        v
[Local Tor routing]
 Tor Browser / Orbot / SOCKS proxy
        |
        | Tor circuit
        | no exit node
        v
[Tor rendezvous point]
        |
        | Tor circuit
        v
[Self-hosted Tor onion service]
        |
        | HiddenServicePort 80 -> 127.0.0.1:8080
        v
[Reverse proxy]
        |
        v
[Bitwarden Server]
 API / Identity / Web Vault

Proposed PR split

                 Proposed PR split
                 =================

+--------------------------------------------------+
| PR 1: bitwarden/server                           |
|                                                  |
| - accept/handle configured .onion hostnames      |
| - avoid breaking URL validation/normalisation    |
| - add server-side tests                          |
| - document server-side limitations               |
+--------------------------------------------------+

                       |
                       | Self-hosted .onion endpoint
                       v

+--------------------------------------------------+
| PR 2: bitwarden/clients                          |
|                                                  |
| - accept valid v3 .onion custom server URLs      |
| - allow http://*.onion where platform permits    |
| - keep ordinary public HTTP restrictions         |
| - add client-side URL validation tests           |
| - document platform-specific limitations         |
+--------------------------------------------------+

I would like to clarify whether maintainers would accept this as two separate PRs:

PR 1 — Server support for .onion hostnames

This PR would focus only on the server-side changes needed to accept and correctly handle self-hosted .onion hostnames where the server currently validates, stores, normalises, or emits configured URLs.

Proposed scope:

  • allow valid v3 .onion hostnames where custom/self-hosted server hostnames are accepted;

  • avoid changing behaviour for ordinary public HTTP URLs;

  • add server-side tests for .onion URL parsing/validation;

  • document any server-side limitations;

This PR would not attempt to make every Bitwarden client work with onion addresses. It would only ensure the server does not reject or mishandle valid onion hostnames.

PR 2 — Client support for .onion server URLs

This PR would focus on the client-side changes needed to configure a self-hosted Bitwarden endpoint using a .onion address.

Proposed scope:

  • allow valid v3 .onion hostnames in custom server URL validation;

  • permit http://*.onion where platform rules allow it;

  • preserve existing restrictions or warnings for ordinary non-onion HTTP URLs;

  • add tests for .onion URL parsing/validation;

  • document platform-specific limitations, such as iOS ATS, browser extension behaviour, Tor Browser/Orbot routing, WebAuthn/passkeys, and HTTP vs HTTPS onion-service trade-offs;

  • avoid adding native Tor routing inside Bitwarden clients unless maintainers specifically want that considered separately.

This PR would not require Bitwarden to operate its own onion service and would not route Bitwarden cloud traffic through Tor. It would only make onion service endpoints configurable by users who already provide their own Tor routing.