Let's begin by assuming that we're operating in either a corporate or Governmental environment where SSL man-in-the-middle interceptions are a given and that *all* traffic on the network between the client and the server is being intercepted and viewed.

Are there any strong authentication schemes that can validate both the client (to the server) and the server (to the client). Ordinarily this can easily be accomplished by an SSL Certificate authentication scheme. Since these are being actively MITM'd this solution isn't adequate.

Any thoughts on a strong authentication scheme that allows both sides to authenticate each other while preventing replay attacks?

(I'm thinking more along the lines of a web-application versus a desktop application)

  • It's not really clear to me what security properties you want. You can implement SRP in javascript, but it'll still be open to many attacks from the trusted MitM. Commented Oct 22, 2012 at 20:28
  • @CodesInChaos Something along the lines of certificate authentication over SSL, but without the SSL bit. You can do something similar with TOTP/HOTP but that requires an external dongle. "There are no standards available right now" is also a perfectly acceptable answer. Commented Oct 22, 2012 at 20:39

4 Answers 4


If your encapsulating layer is insecure, then you can adapt by creating a secure layer within that if you have a known public key ID for the remote host.

Since IP is insecure, we run SSL within it. Since your SSL sessions are forcibly terminated to an unwanted hosted making them insecure, run another secure layer in them such as SSL. SSL over SSL, SSH over SSL, or any other combination of tunneling should provide a trustable connection as long as you verify the host key.

  • Unfortunately in the context of a web-application you can't really verify the server's key for the inner SSL connections. Commented Oct 22, 2012 at 20:51

all traffic on the network between the client and the server is being intercepted and viewed

...implies that it can also be modified - hence no session, no javascript.

along the lines of a web-application

Then the only way I can think of to implement this is via OTPs, and you'd need to disable javascript client side to prevent MITB request forgeries. But since you can't rely on session integrity, you'd need to add a new password to each HTTP request in order to authenticate it. But if you're talking about a securely installed HTML5 application, then that's a different story - you can just implement your own encapsulation of AJAX traffic using symmetric encryption + PSK or one of the growing number of javascript asymmetric libs.

Since these are being actively MITM'd

So you're trying to bypass the local security policy?

  • Not bypass per-se, but ensure security in an insecure environment. I have associates behind some government-induced firewalls that can benefit from something like this as well. Commented Oct 22, 2012 at 21:42

Here's how we do it: http://www.wikidsystems.com/learn-more/technology/mutual_authentication. Basically, the software token validates that the targeted SSL cert that the user gets is the same as stored on the OTP server. If it is not valid, then the OTP is not displayed. The tokens use asymmetric keys to talk to the server, not SSL. Let me know if you want more info.


PSK could, in certain circumstances, be a solution. Encrypt all datas with the PSK. Only allowed hosts will be able to communicate.

You must log in to answer this question.

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