Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

On Thu, Jul 22, 2010 at 10:16 AM, Adam Barth <[e-mail]> wrote:

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

Let's stay focused, we're not talking about securing the DNS protocol or any
protocol other than WebSockets.

You can't prevent someone from sending junk to random network ports.  Each
server needs to harden against that in its own way.  It's tough stuff - and
preventing DoS is even harder.  But WebSockets isn't at fault if a
WebSockets request goes into an existing, un-hardended server and causes
chaos.

The HTTP & Proxy case is interesting, because WebSockets does initiate
through these existing protocols, so I do agree with ensuring that these
cases don't expose new holes.  And in these cases, a frame header would
suffice.


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


I didn't say that - I said it specific could address all 3 of the vectors
Maciej described.


> Of the people posting to this list, only Maciej and
> Ian seem to have sufficient respect for the subtleties of these
> security issues.
>

I'm just saying that its a bummer to put the security fixes into a
synchronous handshake (which requires a RT).  If we could put them into
frame headers which accompany the data, no RT would be necessary.  I believe
this could work.

But maybe it doesn't matter since we're currently discussing running
WebSockets only over existing ports 80 or 443, and those already require a
handshake.  Sadly, with a required handshake, WebSockets will always be
slower (for initial latency) than hanging GETs.  The extra bandwidth is
cheaper than the extra RTs.

>From a performance perspective, some times of interest:
    Average Round Trip Time:   ~100ms
    Serialization latency for HTTP request and response headers (typical
sizes of 350 & 450 bytes) over a 1Mbps link:   ~6ms

If we run WebSockets on non-standard ports, what handshake is required?
 Maybe we should address that in the spec.  It seems this is the only way to
remove a RT.

Mike


> > 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
>