[whatwg] PeerConnection: encryption feedback

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 <matthew at 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<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 11:30:09 UTC