DNS-pointer for detecting on-site Bitwarden

Hi

It would be really nice if Bitwarden had support for detecting self-hosted Bitwarden automatically on login without having to change the server URL in the plugins. For example having a CNAME sitebw.domain.ltd pointing to the on-site server URL bitwarden.domain.ltd and then the users get’s asked if the want to use the company Bitwarden server or not.

That would make the on-site Bitwarden much easer to deploy for 500+ users. :slight_smile:

The right way to do this would be using an SRV-record, not a statically set CNAME-record.

SRV-records are made for service discovery. It’s still the question: For what domain should it look/how does it know the on-site network domain?

1 Like

Yes, you’re right, it should be an SRV record.

The domain name can be extracted from the mail-address used when login in, for company users or for those like me that has their own mail server, or so I was thinking.

1 Like

_bitwarden._tcp.mycompany.com. 3600 IN SRV 5 0 443 bitwarden.mycompany.com.

Parse it like @xlntpete suggests, and use an SRV like that.

1 Like

Is there a way to request a SRV record using JavaScript in a browser? Would be required for discovery on web clients like browser extension.

From what I’ve read, there’s no support for SRV-records in common webbrowsers, mostly due to what they call “broken security model” as there’s nothing that tells weither DNS SRV-record should override A-records and so on.

But what I’m wonder is more simple then that. What if you do a health-check for bitwarden.mycompany.com, and if it checks out fine it asks the user if they want to connect to the selfhosted instance? That would only you to look for a certain answer on that address, set that address as server adress and then connect.

Tagging on to xlntpete, Maybe just even a check for the non-fqdn of bitwarden or some other name, I would assume any organization that has password management, would have the proper forward lookup zones in their environment.

DNS queries such as this should be optional and opt-in only. Lots of reasons from a security perspective where this would not be a good idea – especially since DNSSEC would not be involved. Privacy considerations likewise exist.

The SRV record should contain a hash value which incorporates a pre-shared secret and the IP of the self-hosted Bitwarden server to verify the identity and authenticity of the Bitwarden server before communications are initiated.

If this were to be implemented, SRV records are definitely the correct way to go. Might also consider an option where the domain could be manually specified in the configuration or auto-parsed from the DHCP lease.

1 Like

I think having to opt in kind of defeats the purpose of the request. As already mentioned, SRV record won’t be possible to use since they aren’t available in a browser context.

In other words, correct way to solve this would be to compile the mobile apps and webbrowser applications
with your own self-hosted FQDN-address and distribute them on your own homepage would be the way to go.

Expecting all the customers to install and then manually edit the URL when installing Bitwarden on all their devices is a bit too much to ask from users as I know most of them aren’t that technical :sweat_smile:

Is there a way to distribute browser extensions outside the official stores?

On Wallabag (an open source self-hosted pocket clone), you have a screen “Configure your Android application” in the user settings with a QR code that is displayed.
When you install the application, you scan this QR code and you get automatically the right settings.
Could be a solution, no?

That would only work on something like the mobile apps, but I don’t think that is really much easier than just typing bitwarden.company.com for the server URL.

Would it at least be possible to redesign the initial login view of the plugin so the URL can be changed directly without having to go into the gear-button, would make it easier for unexperienced users, with a text under telling the user to use company Bitwarden web URL or contact support if uncertain. Something like that.

@skavoovie 's idea for a hash in DNS is good. Maybe just do everything in a TXT record, like how DMARC works?

_bitwarden.example.com IN TXT "server=bitwarden.example.com;port=443;hash=(whatever)"

1 Like

TXT record sounds like a good idea, because as @kspearrin pointed out, SRV records are not allowed to be used in HTTP.

The main concern I have with an auto-pointing or auto-checking function like this is – what prevents a MITM attack when a user tries to log into the official Bitwarden or local install web interfaces?

Since the website and the vault use the same password (a design I would personally like to see changed), it seems this would be an ideal tactic to intercept a user’s vault password in order to gain access to their entire vault.

How does a user know they are logging into the true intended Bitwarden web interface if the adversary performs a MITM attack with a CA signed x.509 certificate presented to the client during the MITM attack to avoid browser warnings?

I suppose the same question may exist for the thick client and browser plugins as well?

I’m invisioning some sort of TOFU (trust on first use) auto-generated pre-shared key when the user sets up their vault to be used during each authentication attempt with the browser plugin or thick client.

For a plain web browser, I can’t think of a simple solution, other than to separate the vault and login passwords. FIDO U2F would detect a MITM attack in a browser session, but this is shutting the barn door after cows have already gotten out – FIDO U2F MFA occurrs after the user has already provided their login password, which of course is also their vault password.

In such a scenario, users should be advised that if they ever log into the web interface with FIDO U2F support enabled, and FIDO doesn’t recognize the remote site as valid, they should immediately change their vault password and drop to some other means of Internet connectivity or separate device, as it is possible their password was intercepted in a MITM attack.