Re: Adding Security Considerations regarding interception to p1

Hi Willy, Mark,

On 09/20/2013 06:51 AM, Willy Tarreau wrote:
> 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?

Given that HTTP/TLS is one of the widely deployed countermeasures
on the Internet and is startlingly obvious here, I think saying
nothing about that countermeasure would be pretty dim.

I'm not sure if there's good text somewhere on how to properly
use TLS for HTTP (and I'm not saying I'd insist on that here), but
it'd be a good thing if there were. This line

  "Held / eliminated - Working Group Last Call for HTTP
   Security Properties"

from this wg's charter is sad though.

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

That seems purely pejorative to me. In practice, TLS is the too
that's available here. Ignoring that because its imperfect would
be dumb.

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

I have no idea what you mean. Are you saying that client-auth is
required in order to do better with privacy? That'd seem like a
load of nonsense, so I guess you're not saying that.

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

Now that's definite nonsense. The probability that HTTP (of any
version) will be protected only using technology that's not
genetically related to TLS in 2023 can only be reasonably
estimated at zero.

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

Recent events would seem to indicate otherwise unless you consider
all of Snowdonia to be a "detail".

I would love to see this WG do a great job of helping folks to
deploy HTTP1.1 over TLS better. It should though at least
acknowledge the issues and the major countermeasure that does
get deployed and encourage that. And I think text along the
lines Mark initially suggested, or some of the reasonable
alternative suggestions, seems like the minimum that needs to
be done.

S.

> 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 10:50:54 UTC