[whatwg] PeerConnection: encryption feedback

On 3/24/2011 12:44 AM, Adam Barth wrote:
>
>
> Our experience with WebSockets indicates that masking is still
> important even when communicating between the browser and an
> attacker-controlled server.  The problem is that intermediaries
> attempt to "sniff" the protocol by looking at the bytes on the wire.
> For example, one could easily imagine an intermediary attempting to do
> "helpful" things to transiting UDP packets that look like DNS requests
> or responses.  Rather than play whack-a-mole with these possibilities,
> we're better off building a protocol that's secure by design.

That goal is incompatible with legacy interoperability. It is also 
probably unnecessary in the case where we use real encryption (DTLS / 
DTLS-SRTP) for the media flows.

WebSockets is a special case in that it is trying to look a bit like 
HTTP at the start *and* is TCP/80. The number of cases where UDP 
datagrams are damaged is much smaller and probably much less important 
to solve.

> On Wed, Mar 23, 2011 at 5:13 PM, Matthew Kaufman<matthew at matthew.at>  wrote:
>> On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
>>> I also fail to see the requirement for the masking, given that the
>>> requirement for ICE (at least once the bug of not using passwords in ICE is
>>> fixed) protects against cross-socket attacks.
>> Also agree. The STUN connectivity check message in ICE is sufficient to
>> prove that the far end wants the data... masking to avoid proxies is a
>> non-issue for this channel.
> What makes you so confident that intermediaries aren't listening to
> (and possibly modifying) UDP packets?

What's the threat model here? Are we worried that browsers will send UDP 
flows to endpoints that don't want them (which I claim the STUN 
connectivity test is sufficient to prevent) or are we worried that 
browsers will send UDP flows to endpoints that do want them but that 
something in the middle will break this? We already know that a 
UDP-blocking firewall falls into the second category, so this will 
happen some of the time no matter how much we might not want it to.

>   The entire point of ICE is to
> trick intermediaries (e.g., home routers) into modifying their state
> in certain ways.  It seems entirely likely that the state of those
> intermediaries will further effected by subsequent UDP traffic.

Of course... for starters, the intermediaries will likely reset their 
UDP mapping timers as traffic comes by.

> On Wed, Mar 23, 2011 at 5:21 PM, Matthew Kaufman<matthew at matthew.at>  wrote:
>> On 3/23/2011 3:57 PM, Harald Alvestrand wrote:
>>> That seems like a risk that's not unreasonable to accept, given that we've
>>> survived having the same problem for HTTP links since day one of the Web
>>> (any web page can dupe a client into launching a TCP session to any IP:port
>>> and sending "GET /<ASCII string of their choice>" to it).
>> Agree, and this is even safer because it doesn't burn up TCP state at the
>> target.
> Your assumptions are incorrect.  HTTP has caused a long history of
> security problems in this regard.  Opening up UDP attack surface is
> bad news bears.

Yes, it is, and that is exactly why I have proposed since the beginning 
that we ensure that browsers cannot send UDP datagrams (beyond 
rate-limited STUN connectivity checks whose content isn't controlled by 
the Javascript) to endpoints that don't agree to receive them.

I haven't seen any demonstration that this isn't sufficient to prevent 
the browser from being used as an attack vector, and the only safer 
thing to do is to not add this capability at all.

Matthew Kaufman

Received on Thursday, 24 March 2011 10:20:23 UTC