Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

[Willy Tarreau <[e-mail]>]

On Sat, Nov 27, 2010 at 07:51:17AM -0800, Eric Rescorla wrote:
> Remember that you're talking to the attacker's server. That server generates
> a 200 with a content length of 0. And since requests without content-length
> are assumed to be empty, this is completely compliant.

Requests yes, but responses no ! No new request will be processed by an
intermediary if a response does not have a content-length, because the
end of the response is only defined by the end of the connection.

> I fear you misunderstand the situation. The text above is descriptive of a
> kind of proxy that can fail. We're observing such proxies in the field.

I'm sure you're not observing that precise situation, because those proxies
already cannot correctly work with pure HTTP then. And if those proxies are
so buggy then it's not the goal of WebSocket to try to work around their
HTTP weaknesses. It's the same as for the destIP vs Host header situation.
It's been known for quite a long time that some transparent proxies's filtering
can be bypassed by trying to make them connect to the real destination IP but
sending an accepted Host header. This is not websocket specific, this is a
flaw that impacts their HTTP processing already.

> Well, that may well be true, but what our results show is that current
> intermediaries
> appear to be rather more susceptible to this when Upgrade is used then
> when CONNECT is used.

Once again, I'm not surprized at all.

> > We could also ensure that an exchanged hello frame right after the
> > handshake
> > looks like an un parsable HTTP request/response or a parsable end of HTTP
> > request/response to intermediaries. One such easy solutions would be to
> > prevent any CR or LF byte from being sent in the whole framing. In this
> > case,
> > whatever the handshake, it's really the framing that's protecting you.
> >
> >
> These sound to me like heuristic defenses to protect you from the handshake
> being insecure.

No, those are defenses against the intermediaries that may unexpectedly
think framed data are new requests.

> What's the argument *for* having an insecure handshake?

There's no argument *for* having an insecure handshake, there are arguments
for having a safe HTTP-compliant handshake. The more we rely on corner cases
(eg: invalid host), the more issues we'll face in field due to specific cases
that will have to be handled.

Basically, my feeling is that we're just hacking instead of designing,
and that always leads to unsafe implementations.

> Both of these attacks are outside the Web threat model and enable much more
> serious attacks than WebSockets. In particular:
> 
> 1. If I can modify /etc/hosts (which typically requires root privileges) I
> can inject any malware of my choice onto the machine.

Except that with "websocket.invalid", you just need to access the file *once*
to divert all the traffic to any websocket site forever (ie until the change
is discovered).

> 2. If I can poison DNS, then I can mount cache attacks directly.

Once again, there's a difference between trying to inject a single host
in the hope to collect all traffic and trying to inject a specific host
that some users is supposed to be using.

> I'd rather have something which works by protocol construction than by
> > pure luck because hopefully nobody resolves websocket.invalid.
> 
> 
> It's not luck that people don't resolve websocket.invalid. However, we would
> certainly be willing to choose another bogus Host header that people had
> more confidence in, if that's somehow a sticking point.

I'd rather rely on the underlying protocol semantics and have something which
cannot fail by design than play with corner cases and tricks consisting in
using host names that people are the least likely to try to resolve. I suspect
that once this is deployed, we'll find infrastructures where people will put
these hostnames themselves on some machines in order to be able to solve some
issues, which will re-open a new can of worms.

Regards,
Willy