Re: Hello from Mozilla

On Thu, 16 Jul 2009, Adrian Chadd wrote:
> 2009/7/16 Ian Hickson <ian_at_hixie.ch>:
> > We actually used to do that, but we got requests to make it more
> > compatible with the HTTP Upgrade mechanism so that people could add
> > the support to their HTTP servers instead of having to put code in
> > front of their servers.
>
> Right. So why not extend the spec a little more to make a tunneling
> based upgrade process or something over HTTP?
>
> That way you are still speaking HTTP right until the "protocol change"
> occurs, so any and all HTTP compatible changes in the path(s) will
> occur.

As mentioned earlier, we need the handshake to be very precisely defined
because otherwise people could trick unsuspecting servers into opting in,
or rather appearing to opt in, and could then send all kinds of commands
down to those servers.

> > Well, since Upgrade is a by-hop packet, apparently that's a moot point
> > anyway, because man-in-the-middle proxies will always break it if
> > they're present. So I'm not convinced that allowing HTTP modifications
> > matters.
>
> Ian, don't you see and understand the semantic difference between
> "speaking HTTP" and "speaking a magic bytecode that is intended to look
> HTTP-enough to fool a bunch of things until the upgrade process occurs"
> ? Don't you understand that the possible set of things that can go wrong
> here is quite unbounded ? Don't you understand the whole reason for
> "known ports" and protocol descriptions in the first place?

Apparently not.

> > But the point is that it is a recognisable handshake and so could be
> > implemented as a switch before hitting the HTTP server, or it could be
> > implemented in the HTTP server itself (as some people apparently
> > want). It fails with man-in-the-middle proxies, but then that's what
> > the TLS-over- port-443 solution is intended for.
>
> My suggestion is to completely toss the whole "pretend to be HTTP" thing
> out of the window and look at extending or adding a new HTTP mechanism
> for negotiating proper tunneling on port 80. If this involves making
> CONNECT work on port 80 then so be it.

Redesigning HTTP is really much more work than I intend to take on here.
HTTP already has an Upgrade mechanism, reusing it seems the right thing to
do.

> The point is, there may be a whole lot of stuff going on with HTTP
> implementations that you're not aware of.

Sure, but with the except of man-in-the-middle proxies, this isn't a big
deal -- the people implementing the server side are in control of what the
HTTP implementation is doing.

> I'd rather invest my time in making certain that what you speak on port
> 80 is -still HTTP- (and what you speak to proxies which are relaying
> your websocket data around is also HTTP) right until a well understood
> protocol upgrade occurs.

In all cases except a man-in-the-middle proxy, this seems to be what we
do. I'm not sure how we can do anything in the case of such a proxy, since
by definition the client doesn't know it is present.

On Thu, 16 Jul 2009, Adrian Chadd wrote:
> >
> > Is there a reliable way to open a bidirectional non-HTTP TCP/IP
> > connection through a Squid man-in-the-middle proxy over port 80 to a
> > remote server that normally acts like an HTTP server? If so, what is
> > the sequence of bytes that will act in this way?
>
> That is the wrong question.

It's the question I care about, though.

> The whole point of speaking HTTP on port 80 is to be able to speak a
> variety of sequence of bytes, all which match the HTTP protocol
> specification, in order to get the job done.
>
> At the point you're speaking on port TCP/80, you're not just speaking a
> sequence of bytes any more. You're speaking HTTP. There are plenty of
> sequences of bytes that can occur that are -semantically identical-.

Will _any_ of them reliably open a bidirectional non-HTTP TCP/IP
connection through a Squid man-in-the-middle proxy over port 80 to a
remote server that normally acts like an HTTP server? What would such a
sequence be?

If there is one, then I'd like to use it.

If there is not, then the point seems moot, and there's nothing to be
gained by going the (significantly more complicated) route you advise.

On Thu, 16 Jul 2009, Mark Nottingham wrote:
>
> If you don't already, it would be good to explain the risks of using it
> over port 80 in the document, and perhaps do something stronger to
> discourage such use. Likewise, a note about the dual protocol port not
> being a preferred setup would be helpful, if only in making it go down a
> bit smoother in the IETF.

I've tried to do this. Please let me know if you think the wording should
be stronger; I wasn't exactly sure how much hand-holding was appropriate.
(The text is in the new "Establishing a connection" section.)

Cheers,

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