[whatwg] WebSockets: UDP

[James May]

Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work?

They seem both seem to be session oriented while loosening the other
restrictions of TCP,


On 4 June 2010 00:18, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>
> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/dd7f5269/attachment-0002.htm>