Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

On Thu, Jul 22, 2010 at 8:07 AM, Mike Belshe <[e-mail]> wrote:
> BTW - Isn't the creation of this problem really because we allow arbitrary
> UTF-8 written by the JS application?  If we had a true framing layer (where
> frames have headers, instead of allowing UTF-8), would these attacks be
> real?

Sadly, framing alone isn't sufficient.  Consider a protocol like
DNS-over-TCP that uses the following framing mechanism:

1) Read the first byte and interpret that as the size of the first frame.
2) Attempt to consume the frame.
3) If you fail to consume the frame, advance to the next frame and
return to step (1).

If you send an HTTP POST to a DNS server that's listening to TCP
(which many do), the server will interpret the "P" in POST as the
frame length.  The server will ignore the first frame (because it's
not properly formated) and then 80 bytes into the POST body and try
again.

Now, it just so happens that you can't use browser-generated HTTP POST
requests to screw with a DNS server because every interesting DNS
request must have a NULL byte in it somewhere (as far as I can tell),
and there's no way to generate a POST body from a browser that
contains a NULL byte (at least in Internet Explorer).  In other
browsers (e.g., Firefox), you can get this exact attack to work,
except that Firefox blocks port 53, so they escape disaster by another
means.

The details aren't that important.  What's important is that framing
along is insufficient to protect again cross-protocol attacks because
the other protocol might be using a different framing mechanism.  By
combining the two, you might be able to get the victim protocol to
ignore whatever traps you put in the framing.

> It seems to me that the simplest frame header would be sufficient to
> prevent all of these attack vectors, but the frame headers could contain
> nonces or whatever other security information is needed too.

You should be suspicious whenever someone says XYZ can prevent all
attack vectors.  Of the people posting to this list, only Maciej and
Ian seem to have sufficient respect for the subtleties of these
security issues.

> The reason I mention this is because as we look to using a TLS/NPN, we can
> potentially get rid of the first round trip.  There was a lot of support for
> that idea within the group.  But, we can *only* do so if we don't have JS
> able to write directly to the socket.  If JS is able to write UTF-8 to the
> socket, then skipping the first round trip opens a security vulnerability as
> depicted by Maciej & Adam here.

The essential security property that we need from TLS+NPN is that the
server agrees that it wants to talk web sockets (by agreeing that it's
the next protocol) before we dump anything dangerous on the socket.
You need at least one round trip to the server to get it's consent to
receive attacker-controlled bytes.  I don't see a way around that with
our current tools.

On Thu, Jul 22, 2010 at 9:36 AM, Scott Ferguson <[e-mail]> wrote:
> Actually, let me explain how the non-HTTP version was designed to handle
> cross-protocol attacks, because I didn't explain the reasoning behind the
> design in the draft.

Your analysis is wildly optimistic and doesn't consider protocols like
with framing mechanisms like DNS-over-TCP described above.  You're
just embarrassing yourself.

Adam