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