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

Re: Re[6]: HTTP2 Expression of Interest

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 18 Jul 2012 10:11:22 +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>
Message-ID: <20120718081122.GH5875@1wt.eu>
On Wed, Jul 18, 2012 at 12:50:35AM -0700, Mike Belshe wrote:
> 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 work for one and I can assure you that everyone there says that they're
designing the security model as if communications were clear text (and
they are with regards to the malware ennemy). Certs are marketing only
(show a green cert and reassure your customers).

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

TLS is fine for a very large number of uses and it's already been used where
it's fine. Let's not make it globally worse by forcing incompetent admins to
adopt it without understanding it, which results in end users having to deal
with errors and warnings all the day.

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

No, I'm not saying this at all. I'm saying that we don't need to put locks
on all doors just because one was broken. It's very different. I'm not
advocating for removing TLS, but for keeping it as it is today : used by
those who need or care about it.

It's the same with locks : if you force everyone to add a new lock to their
door, some lock makers will sell many poor quality locks with the same key
reused multiple times and the overall security will be worse because some
people will buy these locks when they need security without knowing how
bad they are.

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

Please, don't confuse 100% secure with "always encrypted". It's really not
the same, and I'm claiming that "always encrypted even when not needed"
will lower the % of secure deployments.

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

Maybe you're just using a small subset of the web then, I don't know. Or
maybe your browser hides the warning for you already ?

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

I'd rather fix real issues than fixing problems we'll create on purpose.

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

TLS on such well-managed sites is not worse (except the extra round trip
which is why I never use TLS on Google, as it increases its load time).

TLS on *every* site is worse.

> The sites which aren't willing to spend the time to keep their users secure
> probably shouldn't be operating.

So we're back to the web-for-the-elite. If you have $100K to spend a year on
an admin to maintain your certs, you're allowed to be connected, otherwise
go away. At least things get clearer now.

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

It's not overly pessimistic, I'm getting them right now while TLS is on a
minority of web sites. When it's 100% of web sites, I'm sure we'll have
browser plugins to automatically validate sites for you !

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

On the wire. Reread what I wrote above. Cookie is stolen in the browser
nowadays, it's easier and you don't need to be connected between the
browser and the server, you just have to stuff your code in every
browser. Much easier and no risk of being caught !

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

It's not a vital part but an additional part. Once again, I'm working
with people who consider that communications are cleartext nowadays. We're
working with ways to secure a browsing sequence when someone else has the
same cookie and browses in parallel. That's not science fiction, that's
todays web and it's been like this for at least the last 5 years.

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

You're right, sorry.

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

I have a different analysis. We're discussing something which is defined
by a minority of web sites who own the majority of the traffic, man power
and even CPU power in the world. It's absolutely normal that protocols
designed in such environments totally forget what a *normal* site looks
like. And it's totally normal that they don't understand why it's hard
to get things to work right at many places.

The 3rd party middleman you're talking about are more commonly in contact
with such real world sites and possibly are more sensible to their concerns
and issues.

> Again, I vote for the user.

I'm for the user too, I just think the model you see for the future user
is a major failure which users will regret because of the increased
issues they will have to deal with without understanding.

Regards,
Willy
Received on Wednesday, 18 July 2012 08:12:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 08:12:13 GMT