HTTPS not secure?

[rakesh mailgroups]

Hi all,

I've just been told that using HTTPS may not be secure enough for a business to business integration system I'm building.

I went looking for more details and I found that a man-in-the-middle attack is possible. My reading of the situation is that if a client asks for a service on port 80, the server responds with a 302 redirect to port 443 and then the communication begins encrypted.

The vulnerability is a potential snooper on the line may see the port 80 request and instead return a different request to the client and then be able to sniff the traffic.

Could this be prevented by just getting the client to go straight to port 443? 

At some point, I have to provide a url for the other organisation to use and I could say its https://mysecuresite.com/blah.

A call to port 80 would return forbidden or something similar.

Would that work?

Thanks

Rakesh

[Fabrizio Giudici]

If you're doing b2b, disabling port 80 is surely doable and it would just
skip the vulnerable step you discussed. But I've got a question: if you
use X509 certificates to authenticate both ends, I don't see how the
fraudulent redirect can harm, at least in the scenario you discussed. If
you're redirected to a false peer, it shouldn't be able to authenticate
with the original certificate. Unless somebody stolen the private key at
the peer, but in this case you've got other problems...

Just my 2 cents in a few minutes. The argument is clearly more complicated.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Reinier Zwitserloot]

As fabrizio hinted at, its possible to do some fairly crazy things with client side certs and other weird in-browser settings no user has ever messed with, but it's there, and if you control both ends of the connection it's an option.

For all other stuff, there are 3 basic concerns about HTTPS:

* One is that browsers will go to 'http://foo.bar/' if you type 'foo.bar' in the browser's location bar, and usually google will send people to 'http://foo.bar/' when searching 'foo.bar'. This is inherently insecure. There is absolutely nothing you can do other than try and impress on users the importance of going to 'httpS://foo.bar/' from the beginning. Sure, you can turn off port 80, but that is irrelevant; you'd have to turn off the man in the middle's port 80, and you can't do that. There is nothing in DNS or otherwise that I know of where you can change things. What could help is to put, on the login page, a specific and explicit reminder to the user that they should be connected with HTTPS to 'foo.bar' and not to some other place. Unless the MITM guy starts from day 1, users will hopefully notice that the login screen changed if the MITM guy removes this message on his fake version of your login screen.

* The second one is that HTTPS isn't quite as secure as you'd think. The infrastructure itself is the problem: Revocations don't really work and various blithering idiots that run the root certs have basically screwed up. It's a lot more complex than that, but long story short, it is no longer valid to state that a trusted domain name + a lock icon to its immediate left in your browser means 'you are absolutely, 100%, guaranteed to be securely talking to the folks you think you are talking to'. Still, it's the best there is, and it rarely goes wrong. For example, the root certs in question have already been kicked out of the root store (IIRC?) of for example firefox and chrome.

* The third and probably most problematic issue is that users simply don't know how to spot warning signs that things aren't as they seem. For example, SSLStrip and I believe Subterfuge do some pretty mean stunts involving SSL: They'll redirect to non-SSL variants (which are then MITMed), or to domains which are different but whose name looks extremely similar to the actual domain name. They run more stunts: They replace calls to /favicon.ico with a favicon that looks just like the lock for the browser the user is using. This shows them the lock icon they are trained to expect without actually being an SSL session, for example. Browsers can attempt to do a little more work on this, but in the end whenever you try to make this idiot proof, the universe just invents better idiots.

[Reinier Zwitserloot]

And minor addendum: Make sure you know what secure=true is in the cookie spec, and use it. This way, if for MITM or other reasons a user goes to http://foo.bar instead of the usual https://foo.bar, the user's browser will NOT send the crendentials to http://foo.bar. This is good, because if it did, you've just lost the security game: A sufficiently skilled MITM can fake it all from there. This doesn't exactly stop all the issues though (the user would end up at http://foo.bar's login screen and probably think: "Huh, I gotta login again. Well, allright, I guess I'll do that", and now you've still lost the security game. But it's better than nothing).