ietf
[Top] [All Lists]

Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

2011-09-06 16:48:07


On 09/06/2011 10:36 PM, Richard L. Barnes wrote:
On 09/06/2011 06:57 PM, Richard L. Barnes wrote:
IMO, this is a pretty strong argument against masking, given how low the 
observed rate of buggy intermediaries is (~0.0017%) and how high the observed 
rate of malware propagation is.


I'm not sure what you're comparing there. Can you elaborate?

Sorry, should have provided references.  The observed rate of cache poisoning 
vulnerability is from the "Talking to Yourself for Fun and Profit" paper.  They 
did an empirical study (using an ad buy) of several variants of the WebSocket protocol.  
They found 8 users vulnerable out of around 54,526 tested. So I actually had my math a 
bit wrong, the prevalence is more like 0.015%.
<http://w2spconf.com/2011/papers/websocket.pdf>

Right. One of my discuss points on this was that they
need to reference.


It's worth noting, though, that their experiment used an older version of the 
protocol (-03 at the latest), and is not compliant with whichever version they 
used.  In particular, they omit the data framing header.  Since these octets 
seem unlikely to increase the probability of a proxy accepting a poisoning 
request, I would regard their number as an upper bound on the prevalence of 
buggy proxies.

Another interesting finding in that paper was that there were no observed 
instances of a CONNECT-based variant of the protocol successfully poisoning 
proxies (on the same sample set of ~54k users).  This might lead one to think 
that the problem that masking solves could also be avoided by using HTTP 
differently.  I think that this option was discussed in the WG and decided 
against, but I don't know why.


In fact, I'm not sure I get the malware argument. Malware
authors are also free to obfuscate or mask their stuff,
when both sides of the conversation but not the intermediaries
are controlled as would be the case here. Or maybe I'm
missing something?

It's a question of how many layers of obfuscation the firewall has to manage.  
Malware scanners have to deal with polymorphism already today, and there are 
lots of approaches, so that's not really an is.  Masking is a layer on top that 
the firewall would have to unwrap.  Just as with 6to4, in principle, masking is 
just an annoyance, another thing to decapsulate.  In practice, firewalls have 
not kept up with these things, so requiring masking on WebSockets is likely to 
create a reasonably long-lived channel for circumventing firewalls.

Ok. Thanks.

I personally think the masking thing is pretty ugly. But I
have to (reluctantly) admit I think it does what its
supposed to do. At this stage I think it comes down to
either doing the masking or not using port 80.

I'm sort of of the same feeling.  I don't disagree that masking solves the 
problem it sets out to.  The question is whether there are other ways to solve 
the problem that are simpler, with fewer side effects.

Fair enough. I think what you're saying is we can go with
masking, or revisit what the WG decided (masking) in
reaction to the above-cited paper, or else get them off
port 80.

Pragmatism is certainly pushing us towards the first of
those;-)

S.


--Richard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>