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).
On Friday, May 10, 2013 3:04:42 AM UTC+2, Reinier Zwitserloot wrote: > > 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.
