Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 stil 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 looking to write 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.

share|improve this question
add comment

1 Answer

up vote 5 down vote accepted

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.

share|improve this answer
    
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 '13 at 18:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.