[whatwg] WebSockets: UDP

[Philip Taylor]

On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller <emoller at opera.com> wrote:
> [...]
> One thing to remember here is that browsers have other means for
> communication as well. I'm not saying we shouldn't support reliable messages
> over UDP, but just pointing out the option.

Yep - the relevant use cases ought to be supported decently by the
platform, but not necessarily by this extension to the platform (it
might be a different extension or it might be (probably is) supported
already).

>> - Protection against an attacker initiating a legitimate socket with a
>> user and then redirecting it (with some kind of IP (un)hijacking) to a
>> service behind the user's firewall (which isn't a problem when using
>> TCP since the service will ignore packets when it hasn't done the TCP
>> handshake; but UDP services might respond to a single packet from the
>> middle of a websocket stream, so every single packet will have to be
>> careful not to be misinterpreted dangerously by unsuspecting
>> services).
>
> I don't quite follow what you mean here. Can you expand on this with an
> example?

I was thinking something like: A host at IP 11.11.11.11 on the public
internet runs some UDP service, like DNS or TFTP or something a bit
more secure. That service is restricted so it only responds to packets
received from IP 22.22.22.22 (a trusted user). The UDP Web Socket
handshake is carefully constructed so that it won't trigger dangerous
behaviour in any of those services (like how the TCP Web Socket uses a
safe HTTP-ish handshake).

An attacker hijacks the IP 11.11.11.11 from the perspective of the
user (by advertising new routes near the user), so the user's packets
to that address go to the attacker. The attacker gets the user to
visit a web page which sets up a UDP Web Socket with the attacker's
server at 11.11.11.11, doing all the handshake authentication
correctly.

The attacker then releases its hijacked address, so any subsequent Web
Socket packets will go to the original restricted service. Since
they're being received from the trusted user, the service will trust
them. Since the web browser has already done the Socket handshake, it
will believe it's talking to a legitimate Web Socket server and will
continue sending whatever data packets the attacker's script tells it
to.

The service will then be receiving and responding to
attacker-controlled packets, and will never have seen the carefully
constructed handshake that's designed to protect it. That's not a
danger for TCP services since they'll reject unexpected packets from
the middle of a TCP stream, but UDP services may accept packets from
the middle of a UDP Web Socket stream.

So it's not sufficient to carefully construct the Web Socket handshake
packets to not trigger unwanted behaviour in non-Socket services.
Every data packet sent on the Socket has to be carefully constructed
too.

(This might be a largely impractical or pointless attack, and there's
probably much easier ways to attack the exposed service, but I don't
know enough about security to judge that. Also I don't know what
packet construction would be sufficiently careful. But it seems like a
possible new concern that's introduced when using UDP in this
context.)

-- 
Philip Taylor
excors at gmail.com