[whatwg] PeerConnection: encryption feedback
matthew at matthew.at
Thu Mar 24 10:20:23 PDT 2011
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
> 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
> 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
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.
More information about the whatwg