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

Re: Adding Security Considerations regarding interception to p1

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 20 Sep 2013 07:51:42 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Mike Belshe <mike@belshe.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Roy T. Fielding" <fielding@gbiv.com>, IETF HTTP WG <ietf-http-wg@w3.org>
Message-ID: <20130920055142.GH28546@1wt.eu>
On Fri, Sep 20, 2013 at 03:14:27PM +1000, Mark Nottingham wrote:
> 
> On 20/09/2013, at 3:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> > 
> > Then what do you think about just describing the current state without
> > giving any guidance about how to protect, so that the reader informs
> > himself on the subject if he feels concerned ?
> 
> 
> Personally - I think that'd be a big improvement over saying nothing.
> However, AIUI the security folks like to see a listing of both threats *and*
> mitigations for them. Stephen?
> 
> The second proposal I made (copied below) tried to make it clear that while
> TLS might help, it's not a panacea. Are you still against it? Would adding
> further qualifications about TLS help?

I thought I had replied but can't find my reply, maybe I dreamed.

I find it better, but I'm still worried about promoting TLS to fix this
with half a solution because we present TLS as a drop-in fix which is not
true. I think there is nothing wrong in saying that TLS completely addresses
the issues only when reciprocal authentication is used (ie where the client
can be trusted as well), and most of the issues (especially related to web
browsing) when the server's authentication is enforced on the client. Also
we must not forget that this will probably be the last spec of HTTP/1.1 and
that it will live forever. Who knows if TLS will still exist in 10 years ?
We killed SSLv2 pretty quickly for example. That's why I'd rather talk about
the principles than explicitly suggesting protocols that we might regret
later (though they should be cited as examples).

Passive interception on the web is just a detail IMHO. TCP connections are
very short and if you miss one request because you could not intercept the
beginning, you'll have the remaining parts a few hundreds of milliseconds
later, and you can even reset the connection to make the client retransmit
in many cases. And if you can sniff, you can intercept and put yourself as
a man in the middle. It is already trivial to do on public WiFi networks.
In switched environments, you even *have* to insert yourself as a man in
the middle in order to sniff the traffic. The only difference between passive
and active interception is with captured traces that you have to analyse
later. So it should be better IMHO to focus on the ability for anyone to
intercept the whole traffic.

A few participants seem to be interested in the approach I proposed,
consisting in describing a number of known threats, and the ones that
can be addressed. The wording is not good, but the general idea was
there. I think that if we could articulate your proposal the same way
it would be more balanced. Do you have an opinion on this ?

Regards,
Willy
Received on Friday, 20 September 2013 05:52:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC