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. On Thursday, May 9, 2013 9:59:23 AM UTC+2, rakesh mailgroups wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
