Re: [hybi] Moving to a CONNECT-based handshake

[Willy Tarreau <[e-mail]>]

On Wed, Dec 01, 2010 at 12:18:09AM -0800, Maciej Stachowiak wrote:
> 
> On Nov 30, 2010, at 11:41 PM, Willy Tarreau wrote:
> 
> > On Tue, Nov 30, 2010 at 11:20:10PM -0800, Maciej Stachowiak wrote:
> >>>  CONNECT * HTTP/1.1
> >>>  Host: realserver.realdomain.com
> >>> 
> >>> A transparent proxy is less likely to interpret this as a correct
> >>> proxy request than it is with "websocket.invalid:443", and at least
> >>> we have the real Host field so that shared environments can deploy
> >>> Websocket.
> >> 
> >> Perhaps CONNECT * is worth testing.
> >> 
> >> But note that a transparent proxy is rather unlikely to interpret any request for websocket.invalid:443 as a valid request, but if it does, it's guaranteed that the hostname will not resolve. RFC2606 reserves the .invalid TLD for domain names that are sure to be invalid: http://tools.ietf.org/html/rfc2606
> > 
> > No, it's guaranteed that such a domain will not be officially registered.
> > It's a lot different. It's similar to the RFC1918 addresses that must not
> > be routed on the net but which everyone learns on BGP from hundreds of AS.
> > 
> > The real issue I see with an invalid name is that it's sufficient to silently
> > put it in a DNS or /etc/hosts so that noone notices it, and the traffic gets
> > silently diverted to the host of choice. Some cheap hosting providers are
> > hacked several times a year, some even a few times a month, and they host
> > thousands of domains. One single change in their /etc/hosts immediately
> > allows all their hosted domains to suddenly offer a websocket service and
> > to be diverted to another random site.
> 
> If your /etc/hosts is compromised, there is nothing the WebSocket protocol can do to protect you. Indeed, your system has likely been rooted. If your local DNS is compromised, then you are highly vulnerable to attacks over HTTP as well as WebSocket (in all its proposed variants).

What I mean is that such a change can remain unnoticed for a very long time
and only divert websocket traffic for sites which do not even plan to offer
such a service. Thus, an intruder may create a websocket service for many
sites without their owners ever noticing.

> > I prefer something which is interpreted improperly and which does not work
> > than something which has chances of succeeding to the wrong place by design !
> 
> That's exactly what I am worried about with * - that it would be mistakenly interpreted as "same host", as it is in OPTIONS, by a transparent proxy.

In OPTIONS, it does not mean "same host" but "this host", the subtlity is
important. There is no notion of forwarding anywhere, just local termination.

> That said, using something that is not even syntactically a valid domain name seems like a reasonable idea, if this is viewed as sufficiently HTTP compliant. I would personally prefer a token that has not been previously given a special meaning at all in HTTP.

I can agree with that.

> > Well, without a proper host name, the following cannot be done anymore :
> > 
> >  - URL filtering (mobile gateways, schools, ISPs)
> >    This introduces a new major security concern
> 
> I am skeptical that URL filtering of WebSocket connections is an effective security measure, or a major concern.

Because you probably have never been confronted to admins having to deal
with irresponsible users. In schools, it's very important. While it can
be accepted to open the service for a specific site (eg: online exams),
they will certainly not want it to be open for social networks or such.

> >  - Websocket for everyone : while Hixie wanted Websocket to be for the
> >    masses, now we're turning to Websocket for the Elite : you will
> >    need to have your own IP address to be able to run Websocket. That's
> >    completely opposite to the directions taken by the HTTP WG which want
> >    to incite IP address sharing.
> 
> I don't see why that is the case.

If the front infrastructure cannot use the Host header to route the
request to the appropriate location, I fail to see how you will offer
shared service for thousands of sites on a single IP.

> >  - Host-based transparent proxying : In his paper, Adam explained how some
> >    transparent HTTP proxies route based on the destination IP address instead
> >    of using the Host header. We all know that using the destination IP address
> >    is dangerous because it makes it easy to bypass filtering rules and/or to
> >    corrupt caches. If websocket does not provide a valid routing information,
> >    the only information transparent proxies will be able to use is precisely
> >    the destination IP address, which will become an incentive for doing that
> >    again.
> 
> For this to be a risk at all, transparent proxies would have to be updated for WebSocket. If they are updated for WebSocket, they can extract the masked true host information for routing.

No, because those transparent proxies won't have to care about WS at all since
we're trying to be HTTP-compliant. Those will remain HTTP-compliant and be
compatible with WS due to WS's compliance with HTTP. Otherwise the need for
compliance is moot.

> > But anyway some of the issues in the paper only involve pure HTTP and dirty transparent proxies. So we're
> > trying to protect from issues that already exist on HTTP itself, which will
> > not improve anything.
> 
> That's not how I read the paper. I see vulnerabilities described in Flash sockets, Java sockets, and some proposed WebSocket handshakes. I do not see any that would work with the HTTP APIs built into the Web platform (XHR, HTML forms, etc).

There is nowhere a WS handshake associated with the demonstrated
vulnerabilities in the paper. There is a case of 2 HTTP GETs through
a proxy which uses the destination IP as a routing info and the
Host header as a caching key (Fig 3 if my memory is correct). This
is already HTTP.

We're trying to focus on existing buggy HTTP components which are already
vulnerable and already corrupt their caches to say that the WS handshake
is vulnerable. This is in my opinion the point that is irrelevant to the
WG, because we're simply swapping the cause and the consequence.

Regards,
Willy