Re: [hybi] [whatwg] WebSockets: UDP

Philip Taylor <> Thu, 03 June 2010 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F303A680E for <>; Thu, 3 Jun 2010 07:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZvMGFDaAjMS for <>; Thu, 3 Jun 2010 07:18:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 44C9E3A6893 for <>; Thu, 3 Jun 2010 07:18:42 -0700 (PDT)
Received: by wyf23 with SMTP id 23so84246wyf.31 for <>; Thu, 03 Jun 2010 07:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WmO1HkdgShbbLWRi4vQ4QzV17FjrWk2PE+7KxCagzHo=; b=dHm8Q48Dqz/oGSOeYnWEpiR/+RqeQ2g9Mg+50xp6+SMpyrks5jIlW5n8XFQxbbFo5O ugjLX9v1pLy7kscvb4m8gQF3zFO9LAIODu+cfU7VDU+cyyht2VsmO8n/cEcNACAcZgX/ hIkRk+hODAvpz/CLLHvQpA5eehAgAy88He8Co=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=whghL1jO7QlOyCW2DcUvAsmuNjUKSNHMFRBL47G1T/mscfmRcCX/weh6bDl5yV/k/X Tp36EkGfr2YSY8fEnSLymp5Q8xamkKMwjmyTzCyQyYRyqwxk7QGxmvVB0GdexgjmP7Ke EnPRFZmokPK6vZDJs5t9xDAi3PaeOsVEp7qBQ=
MIME-Version: 1.0
Received: by with SMTP id r17mr9429213wbw.128.1275574705641; Thu, 03 Jun 2010 07:18:25 -0700 (PDT)
Received: by with HTTP; Thu, 3 Jun 2010 07:18:23 -0700 (PDT)
In-Reply-To: <op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa> <> <op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa> <> <op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa> <> <op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
Date: Thu, 03 Jun 2010 15:18:23 +0100
X-Google-Sender-Auth: NJ0GMWkHjZPxc9FhQ0thKEWlDOU
Message-ID: <>
From: Philip Taylor <>
To: Erik Möller <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 03 Jun 2010 22:26:09 -0700
Cc: "" <>, Hybi <>
Subject: Re: [hybi] [whatwg] WebSockets: UDP
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Jun 2010 14:18:43 -0000

On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller <> 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

>> - 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 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 (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 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, doing all the handshake authentication

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

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

(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

Philip Taylor