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

[Maciej Stachowiak <[e-mail]>]

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

These are plausible threat models, but they are much more severe, and more difficult to pull off, than the "Web attacker" threat model that unencrypted WebSocket seeks to defend against. The protection against active network attackers is SSL (plus possibly Strict Transport Security). The protection against getting rooted is to try to prevent that from happening in the first place.

Keep in mind also that for attacks on DNS to be effective in helping this particular attack, the DNS of your transparent proxy must be compromised, not just of the endpoints. Proxies tend to be on better protected networks. And in the unlikely case you do compromise the DNS of a transparent proxy, then you already achieve global XSS against anyone going through the proxy, without the need to use WebSocket.

> 
>> Thus, I am skeptical that * would be a safer choice. Given what you say about its use in OPTIONS, it seems there is some risk that it might be interpreted improperly by transparent proxies.
> 
> 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.

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 cannot say offhand whether CONNECT with a fake hostname (whether * or websocket.invalid) but a real Host header would be safe. I think we'd have to consider different threats than the transparent proxy attack, e.g. the virtual hosting setup with a malicious server as one node.
> 
> 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.

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

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

> 
>>> Please note that the security issues reported in the paper were
>>> related to the use of HTTP sometimes combined with Flash Player,
>>> nothing was reported for Websocket. I'm not sure you want to
>>> disable HTTP in your browser ;-)
>> 
>> 
>> The cost of entirely removing Flash support would be considerably higher. It's not a viable choice for desktop browsers. But in any case, it's in Adobe's power to address the vulnerability without any changes to standards.
> 
> I don't know who's responsible for how the sockets are used/reused, as I'm
> not aware of internal browser architecture.

Flash sockets don't interact with internal browser architecture. They are solely a feature of the Flash runtime.

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

Regards,
Maciej