[whatwg] PeerConnection: encryption feedback

On 03/23/11 23:43, Ian Hickson wrote:
> On Wed, 23 Mar 2011, Harald Alvestrand wrote:
>> On 03/18/11 21:19, Glenn Maynard wrote:
>>> On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth<w3c at adambarth.com>   wrote:
>>>
>>>> So, the salt and the nonce play different roles.  The salt is to make
>>>> sure the message appears random if you haven't read the spec (and so
>>>> don't know the salt).  The nonce is to prevent the attacker from
>>>> crafting plaintexts that encrypt to a chosen ciphertext, even when the
>>>> attacker sees both sides of the connection.  Picking a new nonce for
>>>> each message means that the attack cannot choose the bytes sent on the
>>>> wire.  The nonce can be communicated in-band, just like the IV for CBC
>>>> mode.
>>>>
>>> If you can send messages to an arbitrary IP address and port, then this
>>> definitely matters: you don't want people to be able to send packets that
>>> look like DNS responses to arbitrary ports, for example.  However, here the
>>> communication is negotiated over STUN/TURN.  The protocol should have
>>> ensured that the port you're talking to is actually expecting to receive
>>> data using this protocol, and isn't, say, a DNS server.  You shouldn't be
>>> able to send data at all except to a peer that agreed to receive data on the
>>> port.
>>>
>>> It's possible that ICE doesn't actually negotiate this securely, since the
>>> STUN server itself is untrusted.  Do you (or anyone else) know if STUN
>>> negotiation is secure under these circumstances?  Or do you think it doesn't
>>> matter?
>> 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.
>>
>> If you're using TURN relays, the TURN server is, of course, involved (it's the
>> relay), but since you're trusting it to be a relay, I don't think there's an
>> additional threat from the fact that it sees the ICE handshake.
> Who is the "you" who is doing the trusting in this scenario?
The browser, or rather: The piece of the browser that ensures that the 
ICE handshake is complete before sending a data packet to the UDP port.
> There are a number of potential attacks here, and a number of players who
> are (or should be) all potentially mutually distrustful -- the user, the
> browser, the origin of the page, the TURN server, the remote peer, and any
> potentially victim host that has no intent in being a party to any
> communication. I haven't yet studied the threat model discussed in this
> thread in depth, but if the threat we're talking about is a cross-protocol
> attack on the potential victim host, then the TURN server can be actively
> hostile and is not trusted by the browser, and the remote peer can be
> actively hostile and is also not trusted by the browser. Obviously it's
> not a problem if the TURN server is hostile and an attack is bounced off
> the TURN server, since the TURN server could just mount the attack
> 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.
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).

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

                   Harald

Received on Wednesday, 23 March 2011 15:57:26 UTC