Firewall block & data transmitted over https

Hello.

I’m blocked by Cloudflare’s firewall whether I connect from my company’s public IP or from my OVH server’s public IP.

The error message is:

Should I contact the support to get them to unlock my IPs? Or what to do?

On a related topic, I’d like to know what kind of information is transmitted over the network when accessing the web vault. I can see something like a hashed password being sent to https://vault.bitwarden.com/identity/connect/token (when the firewall doesn’t block the first call to https://vault.bitwarden.com/api/accounts/prelogin) and since my company can evesdrop all https connections through a man-in-the-middle, I’d like to be sure my master password is safe hashed like it is.

Thank you in advance for your answers

I forgot to mention I found this old topic which didn’t help much CloudFlare issue in Chrome(ium) - Error 1020 · Issue #1017 · bitwarden/browser · GitHub

For a start I would follow the recommendation from the error message: “Please enable cookies”.
If you do not like to use cookies and if this is about the browser then open up a private/incognito window and accept all cookies. Once you close that window they will be gone again.

“Bitwarden is a Zero Knowledge/Zero Trust solution. This means that the team at Bitwarden, as well as Bitwarden systems themselves, have no knowledge of, way to retrieve, or way to reset your Master Password.”

Source: Your Master Password | Bitwarden Help & Support

And for some more details see here:

Thank you very much for your answer.

Cookies are already enabled, I don’t know why this part appears.
My outgoing IPs must be blacklisted, right? Regarding OVH, it’s not the first time a service ban their complete IP range as the servers there are very cheap and therefore many “pirates” run annoying bots on it, but my company’s IP being blacklisted is a real surprise to me.

Yes, I know about the zero knowledge part but I don’t understand this call to https://vault.bitwarden.com/identity/connect/token when logging in to the vault.bitwarden.com webpage:


I’ll try to read the github repo to know more about this but I’m not sure I’ll be able to understand it ^^

Unless you have installed a certificate in the computer (PC? doesn’t looks like macOS) to which HTTPS connections go through, your company can’t decrypt the connection. If you tell me which OS you’re using I can help you to diagnose this.

OTOH, you can have a tunnel just for Bitwarden (and other sensitive connections), granted the more data you transmit through the tunnel the more prone IT are to check what’s going on.

If you need a VPN connection for work you can use a second for this purpose, that’s called split tunnel. The most basic but error-proof solution would be to create an SSH tunnel.

Depending on your setup the best solution changes, let me know if you’re interested on more concrete information.

Yes, this is a company laptop running windows 10 and they have installed a certificate for that.
I am already using a tunnel for sensitive information, and was wondering if I should do the same for bitwarden or if it was unneccessary as everything should be encrypted already.

The problem however is that I get the same error whether I use the tunnel or not.
I didn’t think it would matter but it seems after further tests that my browser being old (based on chrome 72) may be triggering this issue. I’ll upgrade it and report back.

I’d still like to know if I should run bitwarden only through a tunnel or if using it over an eavesdropped connection is fine.

Kind regards

Confirmed, the bug was coming from my old browser. Hopefully it helps people out.
Here are the differences between the headers sent between the old (broken) version and the new (working) version:

Old version-only headers:
accept-encoding: gzip, deflate, br
sec-gpc: 1
pragma: no-cache
cache-control: no-cache
dnt: 1

New version-only headers:
sec-fetch-site: same-origin
sec-fetch-mode: cors
sec-fetch-dest: empty

I still wish to know if I should run bitwarden call through a tunnel or if I’m safe knowing the communication is evesdropped :slight_smile:

Sorry for the delay response, I was on the road out for a funeral. Well, Ive been using Bitwarden in Windows, Linux an macOS and iOS and your issues never happened to me in dozens of installations.

For your specific case, worry not. Even decrypting the connection, there’s no way of decrypting your password. If you need specific details, I can help with that, just grant me a few days, really is a bit hard now.

Be safe, good luck.

Thank you! Yeah, I’ll be waiting, no hurry :slight_smile:

We programmers tend to spit the same technicalities we consume, and the non-technical savvy people just understand bla bla bla… happens the same with lawyers and basically everyone’s jargon.

Bitwarden servers (and if you setup your own, those servers too) are just a dump for encrypted data, unencrypted data never leaves your device (computer/phone). Bitwarden applications doesn’t know your password and they (as a company) have no way of doing a reset, because the “master password” is never stored anywhere. All BW ever sees is a bunch of (nonsensical) encrypted data.

So, how Bitwarden applications know when the password is right? Well, it doesn’t know anything about your password or it hashes. That’s the famous “Zero Knowledge”, in a super crude example this is how it looks like (with tons of added security):

  • [email protected] requests the vault.
  • The vault is transmitted to the device encrypted.
  • The password is used to try and decrypt the vault.
  • If the password is wrong, the decryption returns garbage.
  • If the password is right, the decryption returns normal data.

In fact, the decryption itself doesn’t know when things went ok, as for the algorithm is just: “with this bit of information, apply the encryption/decryption with this bytes of information”. For us is data and password, for the algorithms is far more complex.

So again, how the application knows when a password is the good one? By encrypting a know piece of information; if that information matches means the password is good (and the data isn’t garbage). In other words, when all of your info is encrypted also some small word is used for the comparison.

Is perfectly safe as it has been audited a couple times and has the pertinent certifications that it works the way I described. Bottom line and most important bit is: you unencrypted information never transits the wire.

Hopefully you have a clearer idea of it as a whole, if not I can gladly give you pointers on all the information so you understand what symmetric encryption, key derivation, cyphers and all of the gory small details mean; however that can be somehow overwhelming outside the programming context as that kind of information is never in the Layman form.

Now, in your case, you employer will see your vault in encrypted form, the very same information they will see when scanning the contents of your hard drive and find the file that Bitwarden uses to store the encrypted information (here are the locations).

The sad thing is that if your employer can eavesdrop into your connections they already know your passwords, not because Bitwarden… because when you send them through the sites themselves as the vast majority of sites use simple SSL encryption.

The bug is definitively because of the “old browser” as Bitwarden uses newer approaches to achieve the degree of security it offers. Old IEs, Safari and Chrome don’t have the supported Javascript requirements in their engines to properly handle all the complex encryption tasks.

Good luck!

2 Likes

Hello and sorry for the delay in replying.
Thank you for your well written explanation. Since I already know about the gory details of encryption, I was able to follow well.

However, I was not able to link your explanation with the call to https://vault.bitwa(link broken because I got a “Sorry you cannot post a link to that host.” error)rden.com/identity/connect/token which contains a(n unsalted) password hash. Which part of the authentication needs a password hash?

Kind regards

Certainly you are right, that call shouldn’t send the password. In my case I have TOTP and is sent two times (same password each time, which is not a good thing):

The first call is like this:

https://vault.bitwarden.com/identity/connect/token

scope=api offline_access
client_id=web
grant_type=password
username=REDACTED Email
password=REDACTED base64
deviceType=10
deviceIdentifier=REDACTED GUID
deviceName=firefox

And the answer is a HTTP 400 with a JSON response telling it has an invalid grant, then offering the active 2FA I have, after that a second call is done with this in addition in the payload (after a TOTP is typed):

twoFactorToken=123456
twoFactorProvider=0
twoFactorRemember=0

Then a oAuth2 response with extra information like the session key, and the details of the KDF iterations.

Now I don’t think this should happen, the password is sent and is always the same base64 (I did logged in and out a couple of times and the base64 was the same always). Perhaps @tgreer can shed some light into why this post is hidden and escalate the concern to the developers. I’ve read a few bits and pieces of the jslib project but I’m nowhere near capable of pinpoint all the nitty-gritty of all the involved pieces.

1 Like

Changing the e-mail changes the hashed password so it must be a mix of the e-mail and the password.

The post was hidden I believe due to discourse the speed with which the post was made, if you copy + paste a reply it will flag it as a bot sometimes, nothing intentional.

We turned on some additional Cloudfare rules due to some bot activity a few weeks ago and are tweaking them as needed. If you’re not able to get into the web vault, your best bet is to send a request into our CS team here: https://bitwarden.com/contact with the details, and we can determine the root issue.

Also, if you have questions on how the auth/encryption workflows take place, we have a whitepaper that says it better than I can :slight_smile:

Thank you tgreer.
For Cloudflare, the problem was that I used an old browser, it’s solved already.

From the white paper, I found out that during login (page 9) password+email were encrypted using PBKDF2 and hashed before being sent to the server for authentication. So someone having access to this hash could download the encrypted vault (but not do much with it as it still requires decryption).

This answers the last of my questions on the topic, thank you both!

1 Like