[whatwg] PeerConnection: encryption feedback
ian at hixie.ch
Wed Mar 23 15:43:16 PDT 2011
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?
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.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg