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.

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)

share|improve this question
    
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. –  CodesInChaos Oct 22 '12 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. –  Sean Madden Oct 22 '12 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.

share|improve this answer
    
Unfortunately in the context of a web-application you can't really verify the server's key for the inner SSL connections. –  CodesInChaos Oct 22 '12 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?

share|improve this answer
    
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. –  Sean Madden Oct 22 '12 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.

share|improve this answer

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

share|improve this answer

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.