[whatwg] PeerConnection: encryption feedback

[Matthew Kaufman]

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