The important thing to realize is that intermediaries look at, and can be confused by, traffic destined to the attacker's servers. That's why it's important to mask attacker-controlled data on the wire.
Adam On Thu, Mar 24, 2011 at 10:20 AM, Matthew Kaufman <matt...@matthew.at> wrote: > 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 > >