[whatwg] PeerConnection: encryption feedback

On Fri, Mar 18, 2011 at 11:28 PM, Ian Hickson <ian at hixie.ch> wrote:

> The other ICE peer, the STUN server, the TURN server (if any), and the
> signaling channel are all under the control of the attacker in a worst
> case scenario (the user being directed to a hostile or hijacked site). The
> attacker essentially has perfect knowledge; the only thing we can add that
> the attacker doesn't know is a random number with each packet.
>

The attack, as I understand it, is to trick a user's browser into talking to
an innocent third party (for example, his local DNS server) on a desired IP
and port, and to use the API to send constructed packets at that IP and
port.  The random nonce is intended to prevent the second stage of that:
assume that the protocol can be tricked into sending data to an arbitrary IP
and port, and protect it by preventing arbitrary packets.  (Stop here and
correct me if I'm misunderstanding at this point.)

There are two other parties involved: L, the user whose browser is being
used to send packets, and R, the third-party that the hostile site is
attempting to trick A into sending packets to.

If the attacker can sniff UDP packets sent from L->R, then he does indeed
have perfect knowledge.  However, if an attacker can do that, then he can
also spoof UDP packets from L->R.  This attack is only interesting when the
attacker can't sniff and spoof packets from L->R, eg. when they're behind a
firewall.

If the attacker can't sniff packets from L->R, then L's ICE agent can verify
that R is a real ICE peer, and not a third-party, by sending a packet
containing a random block of data to R.  If that data is echoed back intact,
then L knows R is an actual ICE peer and not an unrelated third party.

ICE does seem to perform this check.  ICE's "basic connectivity check"
(RFC5245 sec2.2) is a STUN packet each peer sends to the other.  That packet
contains a 96-bit transaction ID (RFC5389 sec6) which is echoed back in the
other peer's STUN response.  I could be misinterpreting the protocol.

-- 
Glenn Maynard

Received on Friday, 18 March 2011 21:41:32 UTC