Is server authentication a placebo? (gpgAuth verify step usage in passbolt)

[remy]

From: https://github.com/passbolt/passbolt_cli/issues/12

Currently, passbolt has the concept of a trusted website which can trigger various actions in the extension such as decrypting a password and storing it in the clipboard. Access to this functionality should obviously be restricted as much as possible, which is probably why passbolt’s login procedure has the server authenticate to the client and not merely vice versa.

Problem is, the server authentication as implemented right now is a placebo that offers nothing on top of the usual TLS mechanisms. It works by having the client send a request that only the real server can respond to correctly. However, let’s assume that somebody manages to set up a fake demo.passbolt.com server (getting a valid TLS certificate somehow) and redirect client’s requests to it. The attacker doesn’t need to compromise the real server’s key, they can simply forward the client’s request to the real server and get the right response back. That’s it, the client is now trusting their server and will log in. They can keep forwarding the requests to the real server in order to read the data, or they can produce their own responses in order to trigger extension functionality.

Normally, secure protocols have client and server generate a shared secret during mutual authentication, one that a Man In The Middle won’t see. This secret will usually be used for encryption, or at least as an authentication token for privileged actions. Neither is really feasible the way passbolt is designed, if anything having the server sign privileged actions would be an option (not really trivial).

As it is, server authentication only makes sense if the real server is no longer available. One scenario would be the server being shut down, the domain name freed and then re-registered by an attacker. Having the server shut down while users still expect it to be present isn’t a very likely scenario however. On the other hand, server authentication currently causes a major headache if the server key is compromised and needs to be replaced. Given that, maybe simply relying on TLS for server authentication and recommending additional measures such as Certification Authority Authorization is a better solution.

[remy]

We discussed this with the team and we arrive to the same conclusion. If TLS is broken the server authentication process is flawed. And if TLS isn’t broken the server authentication process is mostly unnecessary. As in the server key verification as you mention is only useful if the original service is shut down and registered again (or seized?), and this an edge case.

Therefore we shouldn’t advertise that the server identity is verified in the sense that we only verify if the server can use the advertised key, as it creates expectations issues. We will make that change in the next version.

Related to this problem as mentioned here, if TLS is broken, then the attacker can also add their own public key and wait/trigger a share operation where they would squeeze in their name and could then access to the decrypted password.

This is also known issue (and one of the reason why we consider passbolt in alpha) which we would like to fix with:

• Have the server sign the body of the response and adding this detached signature in the http headers: this will help make sure an attacker performing a Mim cannot add it’s key or change the list of recipient for a share operation when this list is provided by the server (used for example when getting the list “who is a member of that group”).
• Verify the other users key signatures when importing them in the keyring. We could for example have an admin sign the keys of each users as part of the registration process. This would help in the case the attacker have root access on the server and can edit the keys directly in the database.

Feel free to ask further questions or share your thoughts bellow.

[palant]

You changed the title of this discussion, now it is misleading. GpgAuth is perfectly fine, it’s the way it is being used for passbolt which is flawed - authentication isn’t used to establish a secure communication channel. Now to the more important points:

Have the server sign the body of the response and adding this detached signature in the http headers: this will help make sure an attacker performing a Mim cannot add it’s key or change the list of recipient for a share operation when this list is provided by the server

Ignoring the fact that verifying signature of web pages in an extension isn’t exactly a trivial task, this again protects only against the scenario where TLS is broken. IMHO it is way more likely that the server itself is compromised, and signing responses won’t help you at all then. The issue here is that the server receives too much trust, where ideally there would be none whatsoever. While I understand that the general architecture of passbolt already stands and changing it is unlikely to happen, personally I would have used the server purely as a storage backend with the entire user interface contained in the extension. That would work without giving the server any special privileges or mixing web and extension UI.

Verify the other users key signatures when importing them in the keyring. We could for example have an admin sign the keys of each users as part of the registration process. This would help in the case the attacker have root access on the server and can edit the keys directly in the database.

This will shift the problem but not eliminate it entirely. While an admin user will supposedly have more knowledge to recognize manipulations, tricking them into signing the key for a malicious user should still be possible. For example, a manipulated server might hijack the registration of a valid user and replace their key at this point - the admin will sign the wrong key then. In the end, key exchange needs to happen over a trusted channel, e.g. via in-person interaction.

[remy]

You changed the title of this discussion, now it is misleading

Alright it’s changed back. To be fair the UI at the moment do no mention “server authentication” but “server identity being verified”. The original title could be read as the whole authentication process is placebo, while we are only talking about the verify step. Anyways we agree we need to be clear about what means what in the UI.

I would have used the server purely as a storage backend with the entire user interface contained in the extension

Yes that’s our plan on the long term to move the application in the web extension. This will reduce the complexity in our use of iframes. But doing that alone is not sufficient as one would still need to trust the server with information like described before (the list of public keys, who is a member of what group).

Initially we chose the webxtension + javascript application model following Mailvelope architecture where trusted side like gmx.de have access to an API to request encryption leading to the same kind of issues. We realized along the way that this was not a desirable direction in the long term.

In the end, key exchange needs to happen over a trusted channel, e.g. via in-person interaction.

The key verification and exchange problem is not specific to passbolt. We believe shifting the responsibility to verify the keys to the admin side is a step forward. There are others we could take like allowing users to verify keys with a process similar to whatsapp.

[palant]

The key verification and exchange problem is not specific to passbolt.

I fully agree. In fact, this is probably the toughest issue for any password manager allowing password sharing.