Re: WebSockets negotiation over HTTP

On Fri, 4 Sep 2009, Robert Collins wrote:
> On Fri, 2009-09-04 at 01:44 +0000, Ian Hickson wrote:
>
> > > One very real example of this would be the web server or an fully
> > > WebSocket capable intermediary sending back bytes
> ...
> > > example #1 suppose there was an intermediary translating websockets-over-http
> > > to websockets-port-81 which used HTTP to format said headers of confirmation.
> >
> > Here is the problem I have with this: Why would we suppose the existence
> > of such an intermediary? Why would anyone ever implementa
> > WebSocket-specific proxy?
>
> Welcome to the internet :). Seriously, Why would we suppose the
> existence of an intermediary that intercepts and MITM's SSL connections?

I wouldn't. That sounds like a security disaster.

> Or HTTP - its even got a defined proxy facility, there is no need to
> take over and insert different behaviour, is there?

For HTTP it makes sense since you get edge caching gains.

> We *should* assume that firewall vendors and ISP's will do arguably
> insane things, because they have time and again in the past.

Ok, but that doesn't mean we should go out of our way to make such an
insane thing easier, especially at the cost of security.

> > > example #2 is where the traffic is processed by an HTTP-only
> > > intermediary which sees the 'Upgrade:' header and flags the connection
> > > for transparent pass-thru (This by the way is the desirable method of
> > > making Squid support WebSockets).
> > >
> > > Being a good HTTP relay it accepts these bytes:
> > > HTTP/1.1 101 Web Socket Protocol Handshake
> > > Upgrade: WebSocket
> > > Connection: Upgrade
> > >
> > > It violates HTTP by omitting the Via and other headers your spec omits to
> > > handle. And passes these on:
> > > HTTP/1.1 101 Web Socket Protocol Handshake
> > > Connection: Upgrade
> > > Upgrade: WebSocket
> > >
> > > then moves to tunnel mode for you.
> >
> > Why would it violate HTTP in all the ways you mention? If it goes to such
> > extreme lengths to have transparent pass-through to the point of violating
> > HTTP, why would it then go out of its way to reorder header lines?
>
> Because sysadmins do this!

Not for long, since if they do, it simply won't work. :-)

> Don't ask us to justify the weird and wonderful things we run into.

I'm not asking you to justify the weird things people do; I'm asking you
to justify the request to reduce the security of the handshake to make it
easier for people to do those weird things.

> > From my perspective, such a proxy would raise all kinds of alarm bells to
> > me, and I would be _glad_ that the connection failed. If it didn't, I
> > wouldn't be sure we could trust the rest of the data.
>
> Again, welcome to the internet :P. Seriously, if its not digitally
> signed, you *can't* trust the rest of the data.

Sure. I don't mean to say that I _would_ trust it otherwise, but that this
would just be a warning sign to me.

> > The MITM isn't the WebSocket client. In this situation, it's a
> > (non-compliant, since it forwarded by-hop headers) HTTP proxy. What's
> > more, in this scenario the server isn't a WebSocket server, either,
> > it's an HTTP server. So what Web Socket says is irrelevant.
>
> Note that there are *still* HTTP/1.0 proxies in deployment that don't
> know about hop by hop headers.

It seems highly unlikely that they would act as working WebSocket proxies,
though, right?

> > > > WebSockets, even when initiating the connection by talking to an
> > > > HTTP server and then switching to WebSockets, isn't layered on
> > > > HTTP. It's just doing the bare minimum required to allow the HTTP
> > > > server to understand the request and get out of the way. Once the
> > > > handshake is complete, there is no HTTP anywhere on the stack at
> > > > all.
> > >
> > > Its not doing the bare minimum.
> > >
> > > The bare minimum would be to accept the valid HTTP transforms which
> > > the Internet _will_ perform on the handshake. Discard those useless
> > > transforms and validate the handshake status line.
> >
> > The "bare minimum" is the least amount of processing possible. What
> > you describe is _more_ processing, not less. Therefore it's not the
> > minimum.
>
> The bare minimum would be to just start the tcp connection with
> 'websocket/1.0\r\n'
>
> Stop pretending to be HTTP: use port 80.
>
> Our whole point has been, if you want to "Use HTTP Upgrade", Do It
> Correctly.
>
> If you want to "Use port 80", just do that.

I want to just use port 80, and I want to make it possible for a suitably
configured HTTP server to pass connections over to WebSocket servers. It
seems to me that using something that looks like an HTTP Upgrade is better
than just having a totally unrelated handshake, but I guess maybe we
should just reuse port 80 without doing anything HTTP-like at all.

For now I haven't changed the handshake, since it's not clear that what
benefit it would bring, other than not looking like HTTP, which seems at
most a theoretical advantage, and at worst a disadvantage.

> > > But for 2 you need to use HTTP, which essentially boils down to
> > > defining that one may switch a webserver to use WebSockets by using
> > > the HTTP Upgrade mechanism as defined by HTTP.
> >
> > I understand that you disagree with my interpretation, but my
> > interpretation is that this is exactly what the spec does already.
>
> At this point I think we need to go to the HTTP-WG and discuss further.
> Most of us are already there...

I've long been subscribed to the list and happy to respond to WebSocket
wherever you like. (Please cc me so that I actually see the threads,
though. I filter mail to that list and only occasionally check to see if
I should respond to anything.)

> > > > > 5) Specific mention is made to ignore non-understood headers
> > > > > added randomly by intermediaries.
> > > >
> > > > So long as that happens after the handshake, that's ok, but we
> > > > can't allow that inside the handshake, it would allow for
> > > > smuggling data through,
> > >
> > > If having this view then you CAN NOT use HTTP for the Upgrade
> > > handshake, and MUST use another port and other protocol signatures.
> >
> > IANA expert review has informed me that I must use ports 80 and 443,
> > so there I don't have a choice here.
>
> Whats the message id & what list? I'm extremely happy to jump into that
> conversation.

The number IANA gave me was #257455. I don't know if that helps. I've no
idea whether this gets publicly archived or something.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'