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<w...@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
