W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Moving forward on improving HTTP's security

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 14 Nov 2013 07:45:15 +0100
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "William Chan (?????????)" <willchan@chromium.org>, Adrien de Croy <adrien@qbik.com>, Mike Belshe <mike@belshe.com>, Tao Effect <contact@taoeffect.com>, Tim Bray <tbray@textuality.com>, James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20131114064515.GG10912@1wt.eu>
On Thu, Nov 14, 2013 at 01:37:27AM +0000, Stephen Farrell wrote:
> On 11/14/2013 01:09 AM, Willy Tarreau wrote:
> > least detestable
> 
> The second word of that phrase seems to me to be
> almost perfectly appropriate for MITM attack product
> features. But, importantly, I think your use of
> the phrase does expose the reality of what we all
> think of doing that, even, I suspect and hope, those
> who do it for fun or profit. Thank you.

I don't think anyone really disagrees with this. Amos and Adrien said 
they had to implement this because there is strong demand, not that
they loved the concept. Nobody sane (technically speaking) loves the
concept of trying to fool the user who believes there is some security
when the tools are not designed to inform him about what's happening.

> As to the supposed requirements that lead to those
> detestable product features - if enforcing policy on
> HTTP traffic is what is claimed to be required then
> I would love to see this wg go figure out ways of doing
> that using HTTP (rather than *ab*using TLS) so as to
> not affect the many many other protocols that depend
> on TLS not being as detestable as the implementations
> you're talking about. But personally speaking I don't
> know how you can do that without screwing up the many
> other protocols that depend on https:// and in the
> process making those also detestable.

I think it's neither TLS nor HTTP's role to do to provide the
solution to this, but at least it's certainly not HTTP's role
to make efforts to ensure that this results in the worst
situation for the end user when that's done anyway! In my opinion
it's mostly a matter of user interface as long as the protocol
does not needlessly complicate things.

> Cheers,
> S.
> 
> PS: "Supposed" above is I think fair for most of the
> "requirements" claimed in this space. There is some
> validity to realtime inbound malware scanning but
> the rest seems like nonsense. I do wonder why people
> who pay for those products don't realise this;-)

I would turn the question the other way around : you should wonder why
you believe the rest is nonsense if people are paying a lot for this.
You just don't have the same motivations as them, but for some, it's
just being able to do so or run out of business. And just a reminder,
we started this discussion about the fact that the ones who just MITM
clear HTTP for caching will have a good reason for doing it with HTTPS
if we enforce encryption where not needed. So you add the economics as
a new motivation to do this. For most ISPs, the bandwidth costs are much
higher than anything else, and margins are extremely low. So if the
bandwidth requirements increase, they risk their business. Caching
then becomes mandatory for some. With or without TLS, it's just an
implementation detail when you're talking to someone who doesn't know
if his company will survive past the end of the year.

Willy
Received on Thursday, 14 November 2013 06:45:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC