[whatwg] PeerConnection: encryption feedback

[Adam Barth]

On Wed, Mar 23, 2011 at 4:06 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Wed, Mar 23, 2011 at 6:25 PM, Harald Alvestrand <harald at alvestrand.no>
> wrote:
>> The STUN server is used to obtain your own "public" IP address, for
>> constructing candidate lists.
>> The STUN server is not involved in the ICE handshake.
>
> The STUN server is not.  I believe the STUN *protocol* (packet format),
> however, is.  See RFC5245 section 2.2 "Connectivity Checks".
>
> On Wed, Mar 23, 2011 at 6:43 PM, Ian Hickson <ian at hixie.ch> wrote:
>> directly. The concern is presumably about whether the TURN server, the
>> remote peer, and the page origin can collude to cause the browser to
>> attack the victim directly.
>
> From a *cursory* (an hour or so) examination of the ICE and STUN protocols,
> it appears that even if the web server, STUN/TURN server(s) and a remote
> peer are hostile, it should not be possible to convince a user's browser
> (via its ICE agent) to send packets to an arbitrary IP and port.  It should
> only be possible to send packets to an IP which has handshaked a port via
> ICE.  Obviously, this needs to be confirmed by an expert in these protocols.
>
> *If* that's accurate, does that remove the masking requirement?  16 bytes
> per packet is significant overhead to pay if it's not needed.

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.

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?  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.

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.

Adam