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.