- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 18 Jul 2012 09:27:06 +0200
- To: Mike Belshe <mike@belshe.com>
- Cc: Phillip Hallam-Baker <hallam@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, Rajeev Bector <rbector@yahoo-inc.com>, Martin Thomson <martin.thomson@gmail.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, Doug Beaver <doug@fb.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Jul 18, 2012 at 12:04:47AM -0700, Mike Belshe wrote: > > I'm concerned about the situations where users' security is really > > attacked, > > which is massive MITM using fake certs, massive bank accounts and > > credentials > > collection using malware, spyware returning your browsing history to ads > > vendors, and more recently malware running on smartphones to collect a lot > > of personal information. > > > > Your argument is basically this one: > > "Dear GMail user, Congratulations! You no longer need a password to > access your account! Because hackers have infiltrated TLS, we realize it > is not secure anyway. Therefore, we've decided to remove all passwords so > that it is as easy for you to access your email as it is for the hackers. > Enjoy the new service!" No it's unrelated. My argument is that the sensible services are already TLS enabled and still are already facing the limits of this model. Security people in banks are already saying that they're considering that their users are browsing in clear text since TLS doesn't secure them *at all* right now. They have to invent many mechanisms to prevent malware from stealing passwords and injecting operations. Where is there any privacy in this model ? And when a number of webmail accounts were recently suspected of having been broken after a CA cert break-in, there was no way for the poor user to suspect that his "https://" in front of the URL suddenly was not enough anymore to protect his privacy. > I know there are a lot of types of bad guys. I know there are a lot of > people pessimistic about TLS (me too!). But that doesn't mean that we take > all security out of protocols. That's not I'm saying either. I'm saying that making it mandatory will not improve the sites which already use it and will not improve the sites which deliberately don't want to use it. It will just increase the breach between the two categories and will even more confuse the end user. I understand the benefit of using it for NPN, but that's the only real value. > Server authentication can and does work. It will get even better once we > start using it everywhere. > > Lets be clear: TLS is more work. It's harder. It requires everyone to do > more than they do today. It requires more tools. It requires more > optimizations. But it is absolutely better than where we stand now. We > can make this work - it will take a lot of great engineering, but it can be > done! Don't be so pessimistic as to say "aw, shucks, we can't do it" - I > know for a fact we can. I'm not pessimistic, I'm basing my judgement on what has been done since the beginning. Why do you think that people who deliberately don't care about renewing their certs will suddenly change ? I'm facing cert alerts every day during random browsing. You can be sure it will soon become worse if we force users with even less consideration to produce a cert. We'll be seeing self-signed certs everywhere with a life up to 2038. > Let's vote in favor of the users, and fix the problem. I'm one of the users and I want the situation to improve, not to become worse. Right now the situation is already bad where TLS is used when not needed. And it's bad where TLS is needed because there are many other ways to get the info that is protected only by the transport. > Protocols can and > must be secured. Where they are not, we secure them more. If TLS is not > secure enough, we make it more secure too. Mandating TLS for HTTP will not > be the end of this road - it is just the beginning. But until we take > steps to secure the world, it can never happen. Let's do this!!! Mike, as we discussed a few months ago, I would much more support your proposals of using HTTP over a secured UDP. Really. It would provide exactly the same model as TLS today (one which I'm not satisfied with) but with much improved performance and lower deployment cost. But here we're discussing about making it worse for end users and worse for server admins. That's what I don't like in this model. > > Mandating use of TLS is irrelevant to these real world issues and can only > > make them worse. However I agree it will feel good to say "hey look, now I > > can show you that firesheep doesn't see my cleartext password anymore", > > but what site would require me to send my password in cleartext over the > > net anyway ? > > > > Its not usually about passwords - its about cookie hijacking - going > straight into their sessions and accessing all their info. Steal the > cookie and you're in. Many sites are already sensible to cookie injection and this is something TLS cannot fix. Cookie hijacking has been in used by malware for years, I have proofs of that in many server-side logs where the same session is used in parallel in two countries with completely different browsing behaviours. Sometimes I'm scared because I fell like people who want to push TLS hard really are not aware of the state of the browsing security in 2012, and *this* is even more concerning to me than the overhead of processing TLS! Willy
Received on Wednesday, 18 July 2012 07:27:46 UTC