W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] PeerConnection: encryption feedback

From: Matthew Kaufman <matthew@matthew.at>
Date: Wed, 23 Mar 2011 17:21:31 -0700
Message-ID: <4D8A8E8B.2040703@matthew.at>
On 3/23/2011 3:57 PM, Harald Alvestrand wrote:
> I don't think such an attack is possible; there is no mechanism in ICE 
> for changing the destination IP address without a new handshake.
> The potential attack we can't avoid is that a hostile webapp, possibly 
> with the help of a hostile STUN server, can cause an ICE handshake 
> request to be sent to an UDP IP+port of their choice. The browser can 
> rate-limit such attacks easily, and may implement a port-number 
> blocklist if that seems appropriate (not sending to port 53 seems 
> reasonable).

Exactly. The browser prevents media and data traffic from being sent to 
an address+port unless that address+port has recently answered a STUN 
connectivity check (which itself requires shared credentials between the 
sending browser and the target in order to succeed). The browser 
rate-limits these requests.

STUN connectivity check packets are already carefully crafted (with a 
very long initial magic number) to *not* look like anything else (SNMP 
queries, DNS queries, etc.) and so sending them at a limited rate to 
arbitrary addresses should be safe.

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

Matthew Kaufman
Received on Wednesday, 23 March 2011 17:21:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC