W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Re[6]: HTTP2 Expression of Interest

From: Mike Belshe <mike@belshe.com>
Date: Wed, 18 Jul 2012 00:50:35 -0700
Message-ID: <CABaLYCuL5QuAshYMLxfbQfgKQ2GMTRF3o=r_zJFZctZBkzBiOA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
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:27 AM, Willy Tarreau <w@1wt.eu> wrote:

> 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 ?
>

They're still using TLS for a reason. These broad-stroke statements that
banks consider TLS worthless are simply false.  We can ask any bank about
it if you want.

I am not saying that there aren't security concerns about TLS - but TLS has
served us well for a long time and will continue to do so.  It will be
updated to be better.


>
> 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.


Again, you're arguing that because there was a security breach once, we
should take all the locks off the doors.  This is silly!


>


> > 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.
>

Yes it does.  Neither users nor administrators understand security well
enough.  People forget, they don't know what the padlock means, all sorts
of things.

We can take away this confusion by making it 100% secure all the time.




>
> 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.
>

I don't get these every day.

But if this is a real problem, it will force us to fix the problem and make
it better.  We can innovate here.



>
> > 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.
>


This is like saying "I'll install the airbags when I need them".



>
> > 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.
>

There is no data that suggests it is worse for end users.   With Google,
Twitter, Facebook, every bank in the US all on TLS, its really quite
remarkable that you think that "TLS makes it worse for the end user".

The sites which aren't willing to spend the time to keep their users secure
probably shouldn't be operating.  Hosting sites like amazon, wordpress,
google, and microsoft will take care of the certificate management for all
sites.  The problems you describe of perpetually expired certs is overly
pessimistic.


>
> > > 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.
>

Ah!  TLS makes it almost impossible to steal the cookie.  That's where TLS
kicks in.   As you know, you need many things to keep a system secure; TLS
is just one of them.  But its a vital part!  Without it, you're not a
secure system.



>
> 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!
>

Lets not get personal.

It does not go without notice from me that the battle lines are drawn
around which type of developer you are.  Browser developers and social
content providers are all in the protect-the-users camp (encrypt
everything).  Proxy vendors, which have an uncertain role in an encrypted
future, are unilaterally against it.  This is a power struggle of products.
 Are the endpoints in charge?  Or is the 3rd party middleman in charge?

Again, I vote for the user.

Mike




>
> Willy
>
>
Received on Wednesday, 18 July 2012 07:51:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 07:51:14 GMT