[whatwg] PeerConnection: encryption feedback
matthew at matthew.at
Wed Mar 23 17:21:31 PDT 2011
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
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
More information about the whatwg