We have this web-application with high valuable (business) data.

All communication is encrypted through TLS/SSL. While I consider this a really safe protocol, it can still be compromised if someone managed to install a malicious CA-Certificate my computer.

Since we have the infrastructure, we would like to strengthen the mutual authentication through a Pre-Shared-Key (via SMS).

(I don't want to invent something, but as I see it the PSK should be used to encrypt the underlying stream. Perhaps the surrounding SSL would then even be overhead, but again, I'm not trying to invent my own protocol)

Does anyone know if browsers have support for pre-shared-key encryption/authentication? Perhaps via a plugin? I've searched the web, and found nothing about browser support.

  • This is not exactly answer to your question, but "certificate pinning" could be a solution...
    – myrcek
    Jul 6, 2014 at 12:53

2 Answers 2


Right now, it seems that none of the existing major browsers supports TLS-PSK, and neither to they support TLS-SRP. In your case, both are applicable, but SRP is "stronger" in that it tolerates much better a low-entropy shared secret (say, a password). There has been some initial effort at making Chrome SRP-aware; I don't know how far it went. Since everything PSK offers can be done by SRP and arguably in a better, stronger way, it is plausible that browsers will get SRP support before they get PSK support. But it is not done yet.

In the meantime, you can have some partial workarounds:

  • Have your users employ Firefox, with a specific profile. A Firefox profile includes, in particular, the set of root CA that the browser will use to validate server certificates; let them use an "empty" profile containing only your own CA.

  • Make the users connect through a VPN. In particular a SSH tunnel: SSH can be used as a SOCKS proxy, which the browser can be instructed to use for every connection. SSH's public-key model is CA-less; each user decides which key he accepts or not.

  • Turn the Web application into a genuine, full-fledged application installed on the client system. That application will then do the SSL with your server, and can then choose whatever authentication mechanism it wishes to use.

  • Don't do anything: it is the problem of the client, not yours.

The last "workaround" deserves some extra thinking. Indeed, the problem with potential rogue CA is that these CA are trusted by the client. In a successful Man-in-the-Middle attack, the attacker poses as a fake server, and the client is talking to the attacker, not to you. Therefore, as first approximation, there is nothing you can do in the server which will change what happens between the client and the attacker. In SSL/TLS, the client announces all the cipher suites it is willing to use, and the server then selects one. Even if your server wants to use SRP or PSK, you can bet that the attacker's server will prefer some other cipher suite.

Therefore, assuming that you find an SRP-aware browser, the security of the connection against MitM attackers (who could bribe a CA) relies not on your use of SRP on your server, but on the human user: that meat-bag must expect SRP (or PSK) and call foul play if he does not get it. MitM will be defeated only insofar as the human user, presented with a green padlock and nice login page with your logo and asking for his SMS-obtained password, will say to himself: "hey, this is a Web page, not a browser popup !" and then refuse to connect. If you can make your users reliably react that way, then you can probably train a cat to do the laundry and vacuum-clean the carpets (and then I am highly interested in your services).

This amounts to the slightly depressing following summary: if your users trust rogue CA, then they are already hosed; and there is nothing your server can do to really protect them. First step is to teach them to un-trust existing CA, which will bring back protection (assuming their machines are not already hijacked), but will also "break the Internet" from their point of view.

  • Very clear answer. With the provided links and terms i can follow the subject. Meanwhile, we indeed can consider a VPN solution. Also good to point out a way how such protocol could be attacked.
    – jrnv
    Sep 15, 2013 at 18:10

As mentioned above, it would likely be most easy to add a layer of security by using VPN. Have a look at e.g. https://openvpn.net/index.php/open-source/documentation/howto.html

Once you have created and shared your keys and set up your VPN You can make sure that your Application connects to the VPN IP of your server instead of the public (internet) IP. With this setup you do not even need to set up proxies or anything.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .