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

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 01 Dec 2010 00:18:09 -0800

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

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 1 Dec 2010 09:53:22 +0000

John Tamplin wrote:
> 
>    Should we consider initially supporting only port 443?> 
>    The downsides would be:
[...]
>      * some CPU overhead (though Google publications have indicated this
>        is very low)

* Memory overhead.

It's not unreasonable to consider a large WebSocket server handling on
the order of a million persistent connections.

TLS adds considerably to the minimum memory required to maintain each
socket, if those sockets are set to the minimum buffer size (to save
memory) because they are mostly idle carrying occasional tiny
messages, and used just so the server can send a notification to the
client.

TLS also seems to rule out transparent multiplexing (done by proxies)
to aggregate connections and keepalives, though there is no consensus
in favour of that anyway (and I'm not sure it _really_ rules it out).

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Dec 2010 10:59:52 +0100

On 1 December 2010 08:26, Maciej Stachowiak <[email-masked]> wrote:

>
> I think the experiment demonstrates that the Upgrade handshake itself doesn't protect against this transparent proxy
> attack at all. This leaves framing as the only possible remaining defense, which is rather weak.

I think we all agree that a weakness has been demonstrated.

> I would count this as a demonstrated exploit.

This is an overstatement: weakness!=exploit.    I don't see how
exaggerating the issue helps the discussion.  Too much of the
discussion here is polarised and has a with-us-or-against-us,
all-or-nothing element.   There is no silver bullet here and all
solutions are going to be compromises between multiple concerns.  It
maybe that a weak defence against a few vulnerable intermediaries
(that are now more likely to be fixed) is better than problems that
might come with CONNECT.

We need to consider how we can address the weakness and there is not
just one option.   The options as I see them include:

 + adopting adams CONNECT+bogus host handshake proposal
 + evaluate using CONNECT, but with real URLs and Hosts
 + rigorously analysing the framing to see if it is sufficient defence
against the small fraction of intermediaries that are vulnerable.
 + evaluate what efforts/ideas come out of the wider HTTP community to
address the vulnerable intermediaries. I can't imagine that it is
acceptable that this flash/java exploit will not be addressed, so it
may be that this issue will be addressed in the near future and thus a
framing defence may be more acceptable as a result.

Adams findings do strongly argue for a CONNECT based handshake.  But I
think we need to do more investigations and considerations before we
jump one way or the other.
 + were the vulnerable intermediaries in environments where the
browser had a proxy configured? ie was flash/java being used to bypass
a proxy that would have been used for a real upgrade handshake?
 + How often does a  CONNECT foo.invalid get interpreted by a
transparent intermediary?
 + How does WS framing affect transparent proxies.

I think further experiments using Adam's (and other) methods could be
very revealing.   But these would take a few weeks to take place.

> It's clear that the combination of the two proposals is safer than using neither.

I have to say that it is not very clear at all what defence the bogus
host gives for this particular vulnerability.  I cannot see how the
host header used by the initial request will effect in any way how an
intermediary will treat the data transferred after that request.

As far as I can tell, the bogus host headers are an attempt to protect
non-HTTP and non-WS servers from injection attacks from WS clients.
This is an attack vector entirely unrelated to the host header cache
poisoning that Adam has demonstrated and is probably equally
applicable (or not) to both CONNECT and Upgrade based handshakes.

I'd really like to see a CONNECT without bogus host proposal developed.

In the mean time, I really do not see why we cannot continue to
improve the Upgrade header with some or all of the ideas proposed.
Improving the upgrade handshake does not mean that we cannot consider
CONNECT.

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 01 Dec 2010 02:40:50 -0800

On Dec 1, 2010, at 1:59 AM, Greg Wilkins wrote:

> all-or-nothing element.  

That's kind of the feeling I get when I see people defending the Upgrade handshake after it has been proven insecure. Thank you for keeping an open mind about this and being willing to consider CONNECT.

>  There is no silver bullet here and all

The consequences of this attack are pretty severe. XSS against any site, for all users behind a particular transparent proxy, if only one user behind that transparent proxy visits a malicious Web site. We'd normally consider universal XSS to be a critical vulnerability. The severity is somewhat mitigated in this case since only users in particular unusual network setups are vulnerable. But it is exacerbated, since only one user has to visit a malicious site to have the effect of compromising many users.

If there are problems with CONNECT that are anywhere near this severity, let's hear them.

>  + evaluate using CONNECT, but with real URLs and Hosts

These seem like reasonable approaches.

> against the small fraction of intermediaries that are vulnerable.

This seems like a poor approach. The handshake was a much more elaborate heuristic defense than framing, and we just saw that it doesn't work as well in practice as the CONNECT approach. Doesn't seem like a wise bet. Even if framing turns out to be an effective defense, it's much better to have a secure handshake plus whatever value framing provides, than a broken handshake plus framing.

> framing defence may be more acceptable as a result.

I wouldn't bet on vulnerable infrastructure being fixed any time soon. 

> very revealing.   But these would take a few weeks to take place.

The longer we wait, the more chance that -00 will become the de facto standard.

> non-HTTP and non-WS servers from injection attacks from WS clients.

I don't believe that is the case. As I understand it, the fake hostname exists to protect separate servers in a shared virtual hosting setup from each other. (Perhaps Adam can explain in more detail.)

> I'd really like to see a CONNECT without bogus host proposal developed.

It would be fine to consider the three parts of the handshake proposal separately, as proposed by Eric some time back. 

> Improving the upgrade handshake does not mean that we cannot consider

The Upgrade approach is demonstrably not secure. Continuing to revise a known-insecure mechanism when we could instead adopt a more secure alternative would be an irresponsible course of action.

Regards,
Maciej

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Dec 2010 11:59:16 +0100

On 01.12.2010 11:40, Maciej Stachowiak wrote:
> ...
> ...

As far as I can tell, we have a draft that is stronger than -00, 
although maybe not perfect. Please use it.

Best regards, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 01 Dec 2010 03:39:27 -0800

On Dec 1, 2010, at 2:59 AM, Julian Reschke wrote:

> As far as I can tell, we have a draft that is stronger than -00, although maybe not perfect. Please use it.

Do you mean -03 or Adam's handshake draft? -03 has the same handshake as -00 with the same security flaws. Adam's draft is indeed stronger, but it would be more polite to wait for WG consensus and not just implementor consensus on it, if possible.

Regards,
Maciej

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Dec 2010 12:51:52 +0100

> Do you mean -03 or Adam's handshake draft? -03 has the same handshake as -00 with the same security flaws. Adam's draft is indeed stronger, but it would be more polite to wait for WG consensus and…

It has the same (or a similar) handshake, but a different framing, so 
(as far as I understand), the vulnerability with respect to sending 
messages that might be mis-understood as HTTP is not present.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Dec 2010 14:01:50 +0100

> 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 v…

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.

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

I can agree with that.

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

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

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

> 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 in…

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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 1 Dec 2010 08:45:06 -0800

We all know that WS over port 80 faces obstacles. That's been known for a
long time, nothing has changed, and yet there remains a group that wishes to
try to use it. As long as the problems are known, I see no reason to try to
forbid it.

As for strong objectors, it seems like many people who are implementing have
voiced strong support for adams proposal, modulo some tweaks here and there.
I would like to see how far we can get.

-Ian

On Tue, Nov 30, 2010 at 11:12 AM, John Tamplin <[email-masked]> wrote:

> On Tue, Nov 30, 2010 at 1:39 PM, Ian Fette (イアンフェッティ) <[email-masked]>wrote:
>
>> So, can we make a decision? CCing Joe and Sal, I would like to see a call
>> for consensus.
>>
>
> What exactly would we be making a call for consensus on?  It seems there
> are strong objectors to Adam's proposal.
>
> I have implemented a slightly earlier version (using AES, different bogus
> host header, HTTP headers instead of JSON) of Adam's proposal and it seems
> to work fine.
>
> I still have concerns about WebSocket traffic to port 80 getting through
> any non-transparent proxy however, since all of the ones I have seen are
> configured by default to only allow CONNECT requests to port 443.
>
> Should we consider initially supporting only port 443?  With all the
> attacks on unencrypted connections (such as Firesheep making it easy and in
> the news), it wouldn't be a bad thing to avoid the problem entirely.  That
> would also solve the attacks Adam saw since the proxy can't decrypt the
> traffic to be confused by it, and it should make it easier to traverse such
> proxies since they already work that way to allow HTTPS connections.  We
> could have ws not check the certificate, while wss does, so ws wouldn't give
> protection against man-in-the-middle attacks but wouldn't require the
> servers to have real certificates (they could just use self-signed certs).
>  If we do this, the details of the handshake are less important -- probably
> the v03 handshake is fine.
>
> The downsides would be:
>
>    - virtual hosting WebSocket connections requires TLS SNI support, which
>    AFAIK means the only browser with signficant market share that doesn't
>    support it is IE6
>    - client-side TLS SNI support seems weak (AFAIK, there is no way for a
>    Java client to support it)
>    - some intermediaries may just block it if they can't filter/audit it
>    - some configuration overhead on servers
>    - some CPU overhead (though Google publications have indicated this is
>    very low)
>
> Is this worth proposing on the group?
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Dec 2010 12:21:46 -0800

On Dec 1, 2010, at 8:45 AM, Ian Fette (イアンフェッティ) wrote:

> We all know that WS over port 80 faces obstacles. That's been known for a long time, nothing has changed, and yet there remains a group that wishes to try to use it. As long as the problems are known, I see no reason to try to forbid it. 
> 
> As for strong objectors, it seems like many people who are implementing have voiced strong support for adams proposal, modulo some tweaks here and there. I would like to see how far we can get.

We will get nowhere.  Adam's proposal is to use CONNECT, a method specifically
designed for telling a normal (non-intercept, non-reverse) proxy to create a
TCP tunnel to some other host:port, and he suggest using it to do something
contrary to its method definition and the HTTP architecture in general.
That would violate both CONNECT semantics and the HTTP syntax for non-proxy
requests (not to mention our hybi charter).  Please understand that such an
abomination will not be allowed in an Internet proposed standard even if the
browsers deployed it, and thus should be rejected out of hand.

Listen to the input you have received already.  The vulnerability described
in Adam's paper has nothing to do with the Upgrade handshake -- they
specifically did not test the actual handshake.  What they did is test the
post-handshake non-encrypted connection for intercept proxies that might
(in 8 out of 47,338 cases) mistakenly interpret the unencrypted channel
after the handshake is completed (or ignored).  Thus, it represents
an attack on any non-opaqued channel that is being scanned by caching
intercept proxies (an architecture that is not condoned by HTTP but does
occur in some limited practice by idiots) when a browser is allowed to
send arbitrary bytes over that channel.

One question, therefore, is whether it is important to protect the 0.0169%
of users behind networks that are deliberately using an insecure and invalid
form of HTTP proxy from yet another attack based on that invalid usage.
YMMV.

If it is important, then the solutions are

  a) never use low-numbered ports for websockets [my preference]

  b) obfuscate the data sent via websockets in some way that the client
     page cannot control or deceive. [e.g., encryption, gzip with a fixed
     dictionary, or escaping LF in data.]

  c) establish post-handshake framing that prevents subsequent data
     from being interpreted as an HTTP request or response.
     [e.g., inserting a 'W' after every LF in data.]

Note that none of the above has anything to do with Upgrade or the method used
in the initial exchange.  Labeling the paper as discovering a vulnerability in
the Upgrade handshake is misleading and unethical.

Adam's solution (and EKR's usual hammer) is to use TLS encryption.  That is
fine when it satisfies the protocol use cases, but not so great when it
doesn't.

A more sensible test would have been to use a new method, like WEBSOCKET,
since then at least the initial handshake could remain HTTP-compliant.

BTW, Upgrade was not designed for establishing TLS connections.  Some people
tried to use it that way, three years after it was designed for HTTP/2+,
and failed to get any adoption because Upgrade is hop-by-hop and that's not
what users want from a TLS encrypted stream.  Likewise, using CONNECT to
establish secure tunnels through proxies fell out of favor a long time ago.
The practice of moving such tunnel-oriented behavior onto a separate port has
the benefit of relieving the non-encrypted infrastructure from having
to deal with the very different behavioral and resource-intensive
characteristics of secure connections, which is why I prefer (a) above
whether or not we use TLS (websockets are not the web and do not belong
on port 80).

BTW2, "transparent proxy" != "intercept proxy".  A proxy is called transparent
when it doesn't transform the messages exchanged, unlike intercepts (which
aren't even true proxies since they are unknown to the client).  Please use
the correct terminology.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Dec 2010 12:41:38 -0800

> browsers deployed it, and thus should be rejected out of hand.

You're assuming that the server in a WebSocket connection is an HTTP
server.  It seems entirely reasonable to regard it as a proxy instead.
 In that case, the semantics work out fine.

> send arbitrary bytes over that channel.

Correct.

> form of HTTP proxy from yet another attack based on that invalid usage.

For better or worse, browser vendors feel responsible to protect
"idiots" (as you call them) from themselves.  You might or might not
agree with that decision, but that's unlikely to change.

[...]

> since then at least the initial handshake could remain HTTP-compliant.

Unfortunately, using a new method doesn't solve any of the problems
we're currently worried about.  CONNECT, specially, is useful because
many intermediaries already have the behavior we desire when
processing CONNECT messages.

> aren't even true proxies since they are unknown to the client).  Please use

For what its worth, we researched this issue when writing the paper.
These terms appear to be used interchangeably by most folks, including
Wikipedia.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Dec 2010 22:30:02 +0100

>      [e.g., inserting a 'W' after every LF in data.]

That's why Greg and I keep saying that the framing definitely has an impact
on the whole thing and the handshake does not have to cover everything by
itself (which was proven by Adam's experiments BTW : handshake without WS
data can fool some proxies).

In my opinion, if we can have a framing that never sends an LF (or even
neither a CR nor an LF), there is no way a WebSocket request or response
can be misinterpreted as HTTP. And doing that is not necessarily difficult.
We could think about escaping them or also to work on 7-bit with one bit
always set (eg: bit7==1).

I still find it better to make the protocol safe by design than to try to
escape some known gray areas with some paint, and I'm still convinced that
the framing has a much more important role to play here than the handshake
considering that we want to ensure a buggy intermediary will not accidentely
take the data for an HTTP request.

> fine when it satisfies the protocol use cases, but not so great when it

To be honnest, at one point I wondered whether the goal of the paper wasn't
to get everyone reject it so that we can conclude that HTTP was not usable
and that TLS was the only remaining solution :-/

The sad part is that if we had finished the work on the HTTP handshake
earlier without agitating that many strawmen, we could already be working
on a TLS variant !

> since then at least the initial handshake could remain HTTP-compliant.

It has already been explored, but it happens that stupid proxies have no
reason to make a difference between that an a GET, so if they can fail on
a GET, they can fail on a new method. The point beind the CONNECT is that
it's already a known method with known semantics, eventhough it also has
its share of issues. Alternatively, "OPTIONS *" is also well-defined and
may have less risks of being mis-routed by quick-n-dirty proxies.

> aren't even true proxies since they are unknown to the client).  Please use

I see varying terminologies for that, and I think that it's been caused by
the combined used of such proxies with traffic interception. It's common
to call such proxies "transparent" when they're not declared by the user,
as they're transparent to the user. Thus they act as intercepting proxies.
I often call them reverse-proxies, which is well understood on the server
side but much less on the client side! However I tend to prefer the wording
"gateway" from the HTTP spec is better because it does not preclude one
specific usage. But when explained to network people it creates confusion...

Regards,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Dec 2010 14:15:37 -0800

> In that case, the semantics work out fine.

No.  It could very well be a proxy, expecting to receive both valid
proxy requests (hopefully with some form of authentication) and valid
non-proxy requests.  The CONNECT semantics are clear enough to show
that your request does not follow them, and therefore will be treated
as an error.  That error will result in error logs, occasional pages
to overworked sysadmins, and in rare cases an automatic IPfw block
and a call to the FBI.  This is because CONNECT has been used in the
past by rootkit zombies to attack HTTP servers looking for open
relay proxies.

> agree with that decision, but that's unlikely to change.

You aren't protecting them -- they are already vulnerable to those
attacks via POST and anything else that can send data on port 80.
At best we just avoid piling on.

It is a basic vulnerability of the browser same-origin protocol
to assume that same-IP will result in same-origin.  Combine that
with not retaining control over the Host header field (the actual
same-origin) or the application framing that determines where a
request starts, and then we have a security hole.  That hole can
be avoided for websockets by controlling the post-handshake output,
so browser vendors can happily continue to be responsible for
protecting those admin idiots who feel compelled to install
caching intercepts that don't respect HTTP/1.1 framing, even
if we don't use the proposed CONNECT handshake.

> processing CONNECT messages.

What makes you say that?  CONNECT sent to a proxy doesn't have the
behavior we want unless the host:port is true, and even then the
result is a pure tunnel which will need to start its own handshake.
Most proxies already limit use of CONNECT to specific ports, for
security reasons, so that it doesn't actually get around the firewall
limitations.  CONNECT sent to an origin server doesn't work any
better than a new method.

Changing the method to WEBSOCKET doesn't change the security
characteristics of encrypting the subsequent content, since we
can do that more easily with a new method.

> These terms appear to be used interchangeably by most folks, including

Most folks don't write Internet standards based on protocols that
already contain a different definition for "transparent proxy" (one which
we plan on replacing with "non-transforming proxy" just because of
that confusion).  We use the term intercept because it has no other
confusing-yet-standard definition.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Dec 2010 14:28:17 -0800

> past by rootkit zombies to attack HTTP servers looking for open

Hopefully the FBI will learn to ignore these calls and focus on more
important issues.

> to assume that same-IP will result in same-origin.

The browser's same-origin policy does not make that assumption.
Java's does, however, and it is indeed a security problem for Java.

> Combine that
> request starts, and then we have a security hole.

Are you referring to WebSockets or some other browser feature?  One of
the security invariants browsers enforce is the integrity of the Host
header.

> That hole can

That's true.  Alternatively, we can use CONNECT to achieve the same goal.

> What makes you say that?

The empirical evidence we collected as part of the experiment we conduced.

> CONNECT sent to a proxy doesn't have the

Indeed.  If you read the handshake proposal, that's exactly what we suggest.

> better than a new method.

It seems like you're talking about improving how often the handshake
succeeds in non-attack scenarios.  That's a separate issue.  The
empirical evidence that we've collected suggests that the
CONNECT-based handshake completes roughly as often as the
Upgrade-based handshake.  Of course, both completion rates are
relatively low.  For high completion rates, folks will want to use
TLS.

> can do that more easily with a new method.

We can encrypt subsequent content with the same degree of ease with
either method.

> confusing-yet-standard definition.

Fortunately our paper is not an Internet standard.  :)

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 03 Dec 2010 03:30:54 +0100

>always set (eg: bit7==1).

Using only 7 bits of every byte would require some method to indicate
how many bits are significant, which does not necessarily look very
nice in code; and escaping certain control characters interacts some-
what poorly with prefixed lengths (you have to know how many control
characters there are, check if the encoded length contains them and
then re-adjust the length as necessary; and you have new error cases,
like a message that ends with the escape character).

If, instead, the framing used a delimiter to indicate the end of the
variable length fields, then this would be very simple, you'd just
have a frame structure like

  <flags> <extension data> <delim> <application data> <delim>

where flags is of a fixed length with the most significant bit of each
byte set, and where any offending octet in the data fields is prefixed
by an escape octet. Say, <delim> is "!", <escape> is '"', and you re-
place any octet <= 0x22 by <escape> <octet + 0x80>.

That would make for a much simpler frame structure, an attacker would
be entirely unable to make a browser send anything that looks like a
HTTP request, and when dealing with text the performance impact would
be minimal since you can couple this encoding scheme with your UTF-8
handler (if you aren't working with UTF-8 already). At the expense of
course that you can't handle things as discrete blocks anymore.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Mon, 06 Dec 2010 19:40:37 -0500

> On Nov 30, 2010, at 7:56 AM, Simon Pieters wrote:
> > At Opera we do not plan to implement the new framing until the spec
> >uses a CONNECT-based handshake.

On Tue, 2010-11-30 at 10:24 -0800, Maciej Stachowiak @ Apple wrote:
> We would be hesitant to ship protocol updates that do not fix the
> handshake. Given the security issues identified by the paper from Adam
> and company, we would even consider disabling WebSocket entirely in 

To keep the group apprised of other deployments - the Firefox team is
concerned about the severe implications of a cache poisoning attack
against any of the possible drafts (-76 through -03). I want to publicly
thank Adam, Eric, and the rest of their team for doing the work to
generate a real Internet experiment on a reasonable scale. Such things
are very valuable contributions, even if they don't contain every detail
we might all like to see, are a lot of work, and are all together far
too rare.

Even though the experiment didn't illustrate an exploitable proxy with
any flavor of websocket framing included on the attack vector, given the
liberal parsing culture that surrounds HTTP it seems reasonable to
expect such an implementation may exist and we are uncomfortable
shipping code that could be used to exploit it.

Combining the impact of the risk with the fact that the protocol is
going to evolve and invalidate any shipped implementation anyhow, we
intend to disable by default our Websockets implementation for Firefox
4.0 via a new configuration item. Folks that want to use the -76
implementation to develop against the Javascript API will need to turn
that on explicitly.

I look forward to working with the working group to make a safe and
secure handshake and protocol. As events warrant we will update that old
-76 implementation to a forthcoming revision and re-enable it by default
in a follow-on release. The details of that are unknown right now and,
frankly, subject to the progress of the working group.

-Patrick

-- 
http://www.getfirefox.com/