Subject: Re: workability (or otherwise) of HTTP upgrade

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 01 Dec 2010 03:30:26 -0600

On 11/26/2010 6:55 AM, Greg Wilkins wrote:
> 
> And do you get similar feeling to think about using the CONNECT method
> to establish tunnels for arbitrary protocols?

CONNECT suffers from the same issues you identify is deploying a new port.
Namely, http servers will reject those requests.  Leveraging CONNECT
successfully would require additional HTTP-level authentication to identify
users and prevent abuse (as most proxies do).  Restructuring the internet,
whether it is adding a new port to unblock, or permitting specific classes
of CONNECT traffic, would be a similar battle.

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 01 Dec 2010 03:42:32 -0600

On 11/30/2010 7:24 AM, Eric J. Bowman wrote:
> Julian Reschke wrote:
>>
>> - Uprade to TLS is already defined (although not really used), and 
>> changes the message framing
> 
> I was wondering about that; I've never come across it in the wild, is
> there any data?

Not in a UI-client form that I'm aware of.  Various printer drivers apparently
use this to negotiate secure tunnels to http-aware printers.

---

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

> use this to negotiate secure tunnels to http-aware printers.

If we're including various devices, there are plenty which send
non-HTTP-compliant junk (with a passing resemblance to HTTP) over port
80, and parse their own non-HTTP-compliant junk at the other end.

I haven't seen any like that which are intended to work over the
internet, though.

-- Jamie

---

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

> of CONNECT traffic, would be a similar battle.

Perhaps more to the point, CONNECT is a method that is only allowed to be
sent to a client-side proxy server.  Deliberately sending it in other
HTTP messages would be a violation of its method semantics and the
HTTP/1.1 syntax (because its unusual target syntax is only allowed
when sent to a proxy).

....Roy

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Dec 2010 10:01:09 -0800

> HTTP/1.1 syntax (because its unusual target syntax is only allowed

That seems like a matter of perspective.  When opening a connection to
a WebSocket server, can one not view the server as a proxy sever?

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Dec 2010 19:27:39 +0100

> a WebSocket server, can one not view the server as a proxy sever?

If Websocket was allocated it's own dedicated port (say 6543 for example),
then opening a connection to some.host.com:80 and sending

  CONNECT some.host.com:6543 HTTP/1.1

would definitely be like a proxy server (and it could even be
implemented that way, although I expect many servers would optimise
out the trombone).

But I'm not sure that

 CONNECT some.special.token HTTP/1.1

could be consider a proxy or in the spirit of the HTTP spec.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Dec 2010 19:47:46 +0100

If 6543 is the websocket port, then it would not matter in an
intermediary intercepted and interpreted

as the implementation of that is likely to be exactly the semantics
that we want.

An intermediary that incepts and interpets

is going to break.

On 1 December 2010 19:33, John Tamplin <[email-masked]> wrote:
> On Wed, Dec 1, 2010 at 1:27 PM, Greg Wilkins <[email-masked]> wrote:
>>
> I think the concerns about how this interpreted should only be about
> intermediaries -- the endpoints know that the connection could be a
> WebSocket connection and can process it accordingly.  However, the
> intermediaries cannot be relied on to recognize this, so the question
> becomes which method of sending the WebSocket connection through HTTP
> intermediaries is least likely to confuse them and most likely to transit
> unharmed?
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

---

From: John Tamplin <[email-masked]>
Date: Wed, 01 Dec 2010 18:34:56 +0000

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Dec 2010 16:32:19 -0800

> a WebSocket server, can one not view the server as a proxy sever?

No, because the browser is not limiting such connections to a
configuration-selected proxy (hence, it is not equivalent from
a behavioral or organizational policy perspective, which is
where the name "proxy" came from originally and what drives the
selection and enforcement of proxy use within larger companies).

I don't have a problem with configured proxies being used via
a normal CONNECT tunnel to perform raw websockets access outside
a port-restricted firewall.  That would be a normal proxy
configuration (not intercepts).

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 10:15:46 +1100

Right. Adam is talking about a gateway, not a proxy. 

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 10:17:20 +1100

Adam --

It seems to me we can't really make any progress until we see that the assertion in your first sentence is true; it's certainly possible to construct an insecure use of Upgrade, but that doesn't prove that it's impossible to use it securely.

Any chance of getting that report?

Regards,

On 26/11/2010, at 5:54 PM, Adam Barth wrote:

> Using Upgrade for WebSockets is insecure in practice.  My colleagues
> and I have run an experiment using live traffic on the Internet and
> have successfully exploited a number of users using an Upgrade-based
> handshake (our exploit is harmless by proves the concept).  I'm still
> getting clearance from some affected vendors before releasing a report
> on the experiment publicly.  It's looking like I'll be able to release
> the report within a week.
> 
> Upgrade might well be useful for other purposes, and I think
> definition in HTTP is fine.  The problem is that not everyone
> implements Upgrade properly, which leaves room for an attack to
> leverage an Upgrade-based WebSockets handshake in attacks.
> 
> Kind regards,
> Adam
> 
> 
> On Thu, Nov 25, 2010 at 9:06 PM, Greg Wilkins <[email-masked]> wrote:
>> I'm cross posting this message to both the hybi (websockets) and
>> http-bis mailing list as I think this is an issue that is very
>> relevant to both groups.
>> 
>> The hybi/websocket protocol, as currently proposed, has a handshake
>> mechanism that is roughly based on the HTTP upgrade mechanism.
>> Progress in the hybi/websocket mailing has ground to a halt because we
>> appear unable to get a clear consensus between the two advocated ways
>> forward:
>> 
>>  1) Make the "roughly based" HTTP upgrade mechanism a fully compliant
>> HTTP upgrade.
>>  2) Move away from HTTP upgrade and use another mechanism (potentially
>> CONNECT or SSL extensions)
>> 
>> To paraphrase the arguments against 1), there are some that are
>> concerned that an Upgrade based handshake will never be able to be
>> adequately secured against cross protocol attacks from ws-browsers to
>> non ws-servers. Also there is some concern that intermediaries might
>> not well support Upgrade and that other mechanisms might have a higher
>> success rate.
>> 
>> So I thought that it would be good to move that discussion from hybi
>> to HTTP-bis so we can stall progress here.... no I mean so that we can
>> get a wider view on the capabilities and vulnerabilities that might
>> apply to Upgrade.
>> 
>> My understanding is that Upgrade was included in HTTP for precisely
>> the reason that Websocket wishes to use it - ie to take an existing
>> HTTP connection and to upgrade the protocol run over the connection to
>> something with different capabilities than HTTP.
>> I would also expect that if there are problems with lack of Upgrade
>> support in intermediaries, then it would be easier to get
>> intermediaries to be updated to a standard generic HTTP mechanism
>> rather than some special purpose usage of CONNECT.
>> 
>> If websocket is unable to securely use Upgrade, then there must be
>> some fundamental flaw in Upgrade that should either be fixed in
>> httpbis (if allowed by the charter).   If Upgrade cannot be fixed,
>> then perhaps httpbis needs to somehow deprecate the mechanism and we
>> can look together for alternatives?
>> 
>> So I'd ask the httpbis readers, are there any reasons you know of that
>> would prevent Upgrade being used for websocket?
>> And I'd ask the hybi upgrade sceptics if they could perhaps voice
>> their concerns about Upgrade in more detail than my paraphrasing
>> above.
>> 
>> regards
>> _______________________________________________
>> hybi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hybi
>> 
>

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 06 Dec 2010 15:27:02 -0800

Adam posted his paper to the hybi list a few days ago, it is available here:

http://www.adambarth.com/experimental/websocket.pdf

I'd like to see more detail on the data than is found in the paper, but it seems to show a real-world hazard with use of Upgrade, since many intermediaries do not understand it and at least a few are confused into treating subsequent traffic as additional HTTP requests and responses.

 - Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 10:55:45 +1100

Thanks; will have a read.

Adam -- nice title, not a loaded question at all ;)

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 11:53:49 +1100

I don't think that's the relevant aspect here. "Another port" could be port 80 or port 443 (nasty, and you wouldn't make it the default, but I think you see where I'm going). 

The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.

Cheers,

On 26/11/2010, at 11:55 PM, Greg Wilkins wrote:

> The problem with another port, is that the success rate of  opening an
> arbitrary port through firewalls is not that high.     Thus if
> websocket was allocated it's own sockets, then there would still be
> need for a websocket over 80 protocol (eg like there is BOSH for
> XMPP).

---

From: Adam Barth <[email-masked]>
Date: Mon, 6 Dec 2010 16:59:33 -0800

> Adam -- nice title, not a loaded question at all ;)

That title is optimized to be evocative for the program committee.  We
considered toning it down for you all.  :)

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 06 Dec 2010 17:30:20 -0800

> The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.

Web developers will likely want to operate both a WebSocket service and an HTTP service on the same server, since WebSocket services are likely to be most useful in combination with a Web application that makes use of them. At the same time, they will want their WebSocket traffic to go through firewalls properly. It would be a significant burden if a WebSocket service required a separate domain name, physical or virtual server, and possibly SSL cert.

Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 13:13:28 +1100

> Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.

You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number on two different hosts. 

E.g., someone who doesn't want to buy a separate cert can listen to:

myhost.example.com:80 <-- http traffic
myhost.example.com:443 <-- websockets traffic*

Someone writing a more involved application that needs HTTP-over-SSL as well can do:

myhost.example.com:80 <-- http traffic
myhost.example.com:443 <--- https traffic
websockets.example.com:443 <--- websockets traffic

...by either using their existing wildcard cert, or buying a new one (where the cost is approaching zero).

The problems you point out are, on the server side, trivial to address and nearly non-issues; all of the current approaches seem like way-overengineered premature optimisation. Since you generally can't count on the same process (or box, or even colo, in many architectures) handling two requests from the same client, there isn't any benefit to having them in the same address space, and as already discussed, it adds significant complexities for server-side implementers. 

Regards,

* If you buy into the argument that the only usable ports on the Internet are 80 and 443. Personally, I think this attitude just encourages an arms race with firewall vendors.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 13:48:28 +1100

There's really very little information about Upgrade in that paper; only:

1) Speculation that "many organisations are likely to deploy network intermediaries that fail to implement the Upgrade mechanism..." without any research to support this assertion, and

2) An experiment that shows that *one* Upgrade-based design is insecure. 

I also note that the failure rates for CONNECT vs. Upgrade are almost identical in his experiments.

Cheers,

P.S. Intercepting proxies usually only mess with port 80. Food for thought...

P.P.S. Overall, though, good paper.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Dec 2010 07:10:28 +0100

> You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number o…

In my opinion the problem is not here, but the adoption rate depending
on the port. Many organisations implement URL filtering on port 80,
white-list based filtering on 443 and nothing else around. If you want
to deploy a site which quickly gets a lot of traffic, port 80 clearly
is the most suited, which is even more true considering that long polling
mechanisms already work over that port.

Also, being able to switch from HTTP to WS over a same socket for some
services can save one round trip, but that's marginal in most situations,
except from mobile phones.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 17:14:02 +1100

> mechanisms already work over that port.

Quantify 'many.' According to Adam's paper, ~13% of clients will fail to negotiate with a CONNECT-based solution. Is "many" > 13% of the Internet?

> except from mobile phones.

Would they negotiate back to HTTP if they need to fetch an image?

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 06 Dec 2010 22:16:42 -0800

> The problems you point out are, on the server side, trivial to address and nearly non-issues; all of the current approaches seem like way-overengineered premature optimisation. Since you generally…

I could nitpick your deployment scenarios (I believe they would increase barriers to deployment), however, I wonder what this approach is meant to gain us. Even if declare that WebSocket is not "meant to" be served by the same origin server as HTTP, we still have the following issues:

- We don't want WebSocket to be usable to attack an HTTP origin server. Even if WebSocket connects are not "meant to" go to an HTTP server, an attacker can still choose to do this, so we must defend against this scenario.
- We don't want WebSocket to be usable to attack an HTTP intermediary. The attacks described by Adam and Eric do not depend on the concept that a network protocol is meant to go to an HTTP server, indeed, attacks are possible with Java sockets and Flash sockets, which don't care at all what kind of server is at the other end.
- We don't want WebSocket servers to be easily attackable using HTTP clients built into Web browsers, since we have learned from HTTP's history of cross-protocol attacks and are responsible enough to avoid creating the same kinds of problems.
- If WebSocket was blatantly incompatible with HTTP, the good folks of the IETF would probably not be happy about using it over port 80.

I think this ends up putting us in the same basic design space that we've already been discussing for the WebSocket protocol, even if we don't think it is a recommended setup to serve WebSocket and HTTP from the same port on the same host at the same time. In fact, even if we don't recommend using WebSocket over port 80, as long as the in-browser client lets Web applications choose the port, most of the above issues arise.

About the only simplification from this kind of scheme would be that we don't have to care about making it easy for infrastructure to dispatch between WebSocket and HTTP. We'd just have to make sure HTTP servers will bail early.

Regards,
Maciej

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Dec 2010 19:42:47 +1300

from a proxy / firewall vendor perspective, overloading yet more 
functionality over port 80 CONNECT is something that will simply cause 
us more work, and require us to put more resources into dealing with the 
sort of requests made by CONNECT.

It's bad enough already having malware use CONNECT, so you have to lock 
it down.

Trying to distinguish legitimate use from undesired use gets more 
difficult the more you put over this.

It means you pretty much need to put a firewall and protocol sniffing on 
top of your tunneled connections.

So, where does this lead?  Everyone starts using port 80 for everything, 
and in the end port 80 will be where TCP is now.  Highly restricted.

Except for the additional overhead and complexity = bugs, worse 
performance and security problems.

Maybe we need to stop and think about why the other ports are blocked, 
which compels us to try and circumvent company policy by looking for 
back-door ways to get connectivity.

Mark's comments about an arms-race are spot on.

Whilst you may get good odds of a successful connection now, wait a few 
years when people start locking CONNECT down and it will likely be no 
better than TCP on a different port is now.  Except coaching customers 
to lock down CONNECT is a PITN.

Cheers

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 17:44:19 +1100

On 07/12/2010, at 5:16 PM, Maciej Stachowiak wrote:
> Even if declare that WebSocket is not "meant to" be served by the same origin server as HTTP, we still have the following issues:
> 

These are all absolutely still concerns, but we have proposals for addressing them. 

The difference is that we wouldn't have to figure out how to make it safe *and* compatible with the existing HTTP infrastructure; we wouldn't have to catch all of the accidental / deployment issues as well as the active attacks.

That would make the way forward fairly simple:

1) Designate a new port for Websockets traffic
2) Allow that to be overridden (much as with HTTP and pretty much every other protocol) for people who have immediate deployment considerations (i.e., they'll use 443)
3) Design the protocol so that it can't spoof other protocols, by using a selection of techniques:
  a) Exchanging a nonce, with HMAC response
  b) Armouring each message 
  c) Encrypting the whole damn thing
*without* the pretence that it's HTTP.

I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe deployment strategy, whereas #2 lets the impatient deploy right away, and also gives a fallback if #1 doesn't take off in the long run.

Cheers,

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 06 Dec 2010 23:04:55 -0800

> These are all absolutely still concerns, but we have proposals for addressing them. 

Indeed, we do, and they result in something that is reasonably HTTP-compatible, enough that you could make a two-way server. 
> I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe deployment strategy, whereas #2 lets the impatient deploy right away, and al…

Adam and Eric's proposal basically does what you say, except that it doesn't designate a new port for WebSocket traffic, and it makes a small nod towards letting servers and server-side infrastructure dispatch between WebSocket and HTTP on the same port. I am not sure it would simplify things much to abandon those goals.

If the goal was not to interoperate with HTTP at all, it would be much better to use an approach where everything is encrypted. One plausible way to do that would be to restrict the protocol to TLS-only, at which point the nextprotoneg proposal can take care of dispatch without having to involve the HTTP layer. I think this is a plausible option, but many hybi WG members have expressed concern about the performance issues and other barriers to deployment of an all-TLS solution.

Another approach is to invent our own crypto and start with a key exchange. Inventing crypto makes me nervous compared to using something known (such TLS), and might well impose many of the same costs that folks are worried about with TLS.

It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group. We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Dec 2010 08:25:17 +0100

> and in the end port 80 will be where TCP is now.  Highly restricted.

There's a difference between port filtering and protocol filtering though.
Port filtering brings nowhere without protocol filtering. Right now I'm
used to SSH home on port 443 from various places. So a port means nothing.
Also, there's a reason CONNECT is used a lot : it's supposed to be a blind
tunnel which is not easy to filter. Port 80 has clear defined semantics
and only HTTP passes into it. If we use an Upgrade-based method instead
of a CONNECT-based method, it is perfectly possible to build filtering
proxies which will consider the Upgrade header and ensure that the upgraded
protocol really matches WS framing. The CONNECT does not define the upgraded
protocol, reason why it's harder to filter on it.

In fact, I'd say that the more ports we open, the more complex rules we
have in the end because we already know that many protocol-port combinations
will have to be filtered anyway.

In fact if HTTPS made use of Upgrade instead of CONNECT, we would not have
the current mess with malware or SSH abusing CONNECT.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Dec 2010 08:29:39 +0100

> Quantify 'many.' According to Adam's paper, ~13% of clients will fail to negotiate with a CONNECT-based solution. Is "many" > 13% of the Internet?

We have no idea where it was measured. If it's in a campus, 13% of failure is
high, considering the general low amount of filtering at those places. If it
was in corporate networks, 13% is low. It also depends on what's the target
for a site which makes use of WS. Individuals are not a problem. Neither are
mobile users because their operator will be able to quickly open a new port.
Schools and corporate networks where admins are responsible for the filtering
definitely are the slower adopters.

> Would they negotiate back to HTTP if they need to fetch an image? 

No, once upgraded (whatever the method) we can't reuse the connection to
get back to HTTP.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Dec 2010 08:31:36 +0100

On 7 December 2010 08:04, Maciej Stachowiak <[email-masked]> wrote:
>> I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe
> deployment strategy, whereas #2 lets the impatient deploy right away, and also gives a fallback if #1 doesn't take off in the long run.
>
> Adam and Eric's proposal basically does what you say, except that it doesn't designate a new port for
> WebSocket traffic, and it makes a small nod towards letting servers and server-side infrastructure
> dispatch between WebSocket and HTTP on the same port. I am not sure it would simplify things >
> much to abandon those goals.

I don't see the justification for the confidence in Adam's and Eric's
proposal.   Basically they are saying that in their experiment sending
the method "CONNECT" was sufficient to prevent intermediaries parsing
any following HTTP requests.

Yet when the suggestion of sending Get+Upgrade+Hello packets is made,
to similarly trip up the parsers of intermediaries, the response is
that HTTP parsers are forgiving and that empirical experiments of no
exploit are not proof that it is safe etc. etc.     These arguments
can be equally made against a CONNECT solution, as it is easy to
believe that their are intermediaries that will treat CONNECT no
differently from other methods and continue parsing the stream for
HTTP content.

We need to do the experiment, but I expect we would find that a
GET+Upgrade+Hello handshake would also have 0 exploits just like
CONNECT.   But I do not believe that either zero result proves that
either handshake is 100% safe, because essentially the issue is caused
by poor intermediaries and we can always imagine more buggy
intermediaries.

After either "CONNECT" or "GET+Upgrade+Hello" we will need to have
robust framing that gives a high probability of tripping up HTTP
parsers on every message.    But for both handshakes, the defence is
essentially probabilistic, because we cannot prove that there is not a
really stupid intermediary out there.     I think it is just wrong to
think that "CONNECT" makes us any  safe from this consideration.

The question is, given that these intermediaries are already
exploitable via commonly deployed browser plugins (and the victim does
not even have to be running those plugins as another browser can do
the poisoning), is a probabilistic demonstration of robust framing
acceptable defence for either handshake?

If the answer is no for one, then it is no for the other, because
there is no difference in the proofs for either.   If the answer is
no, then we need to consider encryption or another port.

I do come back to the fact that using another port does not give a
perfect success rate, but then neither does CONNECT or
GET+Upgrade+Hello.    Opening new ports seams like an easier ask than
convincing intermediaries to change their CONNECT and/or Upgrade
handling.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 07 Dec 2010 00:07:32 -0800

> differently from other methods and continue parsing the stream for

Empirically, it seems the number of servers confused in this way by CONNECT is significantly lower than the number confused by GET+Upgrade, to a statistically significant degree, and there are good odds that it is close to 0. There is a plausible theory to explain these facts - CONNECT is very often supported by proxies and other intermediaries with a specific behavior which precludes this failure mode. Meanwhile, GET+Upgrade is not used much, so intermediaries do something random and possibly bad when faced with it.

That being said, the Adam+Eric proposal also includes obscuring routing information and masking of the payload, which also defend against the intermediary attack.

Finally, we also need to worry about attacks on HTTP origin servers, WebSocket servers (against http attackers) and server side infrastructure, including in virtual hosting scenarios.

The Adam+Eric proposal is the best I have seen for addressing these threats.

> by poor intermediaries and we can always imagine more buggy

It's worth testing. But GET+Upgrade+Hello requires an extra round trip to set up the connection. Between an extra round trip and possibly violating the vaguely defined "semantics" of the CONNECT method, I'll take the semantics violation. 

Furthermore, GET+Upgrade+Hello doesn't do as good a job of defending against the other threat models we've discussed. You could combine it with masking of the payload and routing information, but at that point I don't think you could claim even a "semantics" advantage relative to CONNECT.

> convincing intermediaries to change their CONNECT and/or Upgrade

It might be worth testing a new port (not 80 or 443 or any other well-known port) for success rate. It would also be worthwhile comparing TLS over port 443. It may be that 443 is the only option that gives a resonable success rate.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Dec 2010 09:18:00 +0100

On 7 December 2010 09:07, Maciej Stachowiak <[email-masked]> wrote:
>
> It's worth testing. But GET+Upgrade+Hello requires an extra round trip to set up the connection.

There is no extra round trip for GET+Upgrade+Hello as it is proposed.

There would be an extra round trip if we want to wait for confirmation
from the browser that a server-nonce has been hashed correctly, but
this xtra RTT would apply no matter what handshake is used.

> Furthermore, GET+Upgrade+Hello doesn't do as good a job of defending against the other threat models we've discussed. You could combine it with masking of the payload and routing information, but a…

Indeed - the protections against the other threat models can be
applied equally to either handshake.  They are essentially unrelated
to CONNECT or GET+Upgrade.

> It might be worth testing a new port (not 80 or 443 or any other well-known port) for success rate. It would also be
> worthwhile comparing TLS over port 443. It may be that 443 is the only option that gives a resonable success rate.

See the data I just posted to the other thread.  High well known ports
are no worse than using port 80 and using 443 is not that much better.

cheers

---

From: Dave Cridland <[email-masked]>
Date: Tue, 07 Dec 2010 09:42:05 +0000

On Mon Dec  6 23:27:02 2010, Maciej Stachowiak wrote:
> I'd like to see more detail on the data than is found in the paper,  
> but it seems to show a real-world hazard with use of Upgrade, since  
> many intermediaries do not understand it and at least a few are  
> confused into treating subsequent traffic as additional HTTP  
> requests and responses.

That's a subtle misread of the paper.

The paper shows that many intermediaries treat any traffic as HTTP  
requests and responses until they find a CONNECT, after which they  
treat the traffic as opaque except in a tiny minority of cases (what,  
4 out of 54,000?).

The paper makes no stance on whether Upgrade itself is problematic,  
just whether CONNECT is sufficient to break the intermediaries'  
assumptions.

Hence my suggestion that an ideal solution is to have the initial  
traffic from the client within the websocket appear to be a CONNECT  
(albeit, a deliberately broken one akin to Adam et al's paper).

What this results in is in formal terms, an Upgrade to Websocket  
happens, whereas to a naïve third party intermediary, there is a GET  
or POST followed by a CONNECT.

No specifications were harmed in the making of this suggestion...

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: John Tamplin <[email-masked]>
Date: Tue, 07 Dec 2010 09:31:26 +0000

> convincing intermediaries to change their CONNECT and/or Upgrade

I asked if we should consider that option in
http://www.ietf.org/mail-archive/web/hybi/current/msg04563.html and
there seemed to be little support for it and would require changing
the charter of the group.

Options at this point:
 1) stick with GET+Upgrade, which probably means masking
     everything in the payload in a way which can't be attacker
     controlled, which seems expensive
 2) convince detractors that using CONNECT as proposed is
     not violating the HTTP spec
 3) use a dedicated port, which means changing the charter
     and still requires addressing cross-protocol attacks in
     attacker-controlled payload
 4) wait for TLS-NPN or just use GET+Upgrade always over
     TLS on port 44 (ws vs wss would indicate whether to
     validate the cert)
 5) something else that hasn't had much discussion, such as
     POST chunked encoding in each direction

Any other options?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 21:53:03 +1100

> Indeed, we do, and they result in something that is reasonably HTTP-compatible, enough that you could make a two-way server. 

"Reasonable" is a judgement call, and from what I see, there's disagreement about this, much coming from the people making those servers.

[...]

> Another approach is to invent our own crypto and start with a key exchange. Inventing crypto makes me nervous compared to using something known (such TLS), and might well impose many of the same co…

These are two possible approaches, but they aren't they only approaches possible.

> It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group.

No, the charter says nothing about what port(s) the protocol will run over. The requirements you refer to are a -01 draft, so they don't represent IETF consensus. Have there been any WG consensus calls on them?

> We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board.

AIUI changing the handshake is already the subject of a lot of discussion, so this is hardly "going back to the drawing board."

I fully agree we need to unblock this discussion and ship a protocol. I'm trying to understand why people are digging in their heels on a design that's supposed to be helping server deployment, when AFAICT the server folks are telling them it's not workable.

Regards,

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Dec 2010 12:09:16 +0100

On 7 December 2010 11:53, Mark Nottingham <[email-masked]> wrote:
> I fully agree we need to unblock this discussion and ship a protocol.
> I'm trying to understand why people are digging in their heels on a
> design that's supposed to be helping server deployment, when
> AFAICT the server folks are telling them it's not workable.

>From my point of view, the only things in play that are not workable
are the unframed bytes in the current draft and the bogus hosts in
adam/erics proposal.

But from a server implementers point of view, both CONNECT and
GET+Upgrade+Hello are workable handshakes, so I'd really like to see a
draft based on either of them, but with the unframed bytes and space
encoding strangeness removed, maybe also with the robust framing
(invert FIN bit) and Hello frames used.      Either one has hurdles to
overcome, but they can hardly be worse than what we currently have.

My preference is to come up with a draft based on GET+Upgrade+Hell,
but the browser vendors appear more included to go with a CONNECT
bases solution, so if that's what we need to do to get rid of the
deployed -76 implementations, then I think it is a good next step.
The -76 implementations violate HTTP spec to a much greater degree
than the expressed concerns about CONNECT

cheers

---

From: Joe Mason <[email-masked]>
Date: Tue, 7 Dec 2010 10:27:20 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Maciej Stachowiak
> Sent: Tuesday, December 07, 2010 2:05 AM
> To: Mark Nottingham
> Cc: hybi HTTP; HTTP Working Group
> Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
> 
> If the goal was not to interoperate with HTTP at all, it would be much
> better to use an approach where everything is encrypted. One plausible
> way to do that would be to restrict the protocol to TLS-only, at which
> point the nextprotoneg proposal can take care of dispatch without
> having to involve the HTTP layer. I think this is a plausible option,
> but many hybi WG members have expressed concern about the performance
> issues and other barriers to deployment of an all-TLS solution.
> 
> Another approach is to invent our own crypto and start with a key
> exchange. Inventing crypto makes me nervous compared to using something
> known (such TLS), and might well impose many of the same costs that
> folks are worried about with TLS.

If we are going to encrypt everything, we should just use TLS.  Crypto is an especially bad place to be reinventing the wheel.  As far as I know all the performance concerns apply to any encryption, even simple XOR masking, so there's no point in discussing tradeoffs of various implementations - the tradeoff is whether we want encryption at all.  Once we're over that hump, I don't think any custom encryption scheme is going to have benefits that outweigh TLS's huge benefit of "well understood and in wide use".

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 07 Dec 2010 15:47:54 -0800

> No, the charter says nothing about what port(s) the protocol will run over. The requirements you refer to are a -01 draft, so they don't represent IETF consensus. Have there been any WG consensus c…

Not on the whole document, but there have been consensus calls on specific items in the draft, notably including the "share a port" item and the related concept of http compatibility.

> I fully agree we need to unblock this discussion and ship a protocol. I'm trying to understand why people are digging in their heels on a design that's supposed to be helping server deployment, whe…

The main complaint about CONNECT from server folks seems to be literally a question of semantics. There is also the related practical issue of having to turn off alerts on CONNECT attempts if you want to serve WebSocket.

If there are other proposals that would work better and serve the same use cases, that would be useful input to the conversation. "Don't try to share a port with a Web server" is not a sufficiently fleshed out proposal to move the conversation forward, and does break some use cases that were identified as desirable. If someone cares to present a more concrete proposal, we'd be in a position to evaluate the tradeoffs.

Regards,
Maciej

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Tue, 07 Dec 2010 18:00:10 -0600

On 12/7/2010 5:47 PM, Maciej Stachowiak wrote:
> 
> If there are other proposals that would work better and serve the same use cases, that
> would be useful input to the conversation. "Don't try to share a port with a Web server"
> is not a sufficiently fleshed out proposal to move the conversation forward, and does
> break some use cases that were identified as desirable. If someone cares to present a more
> concrete proposal, we'd be in a position to evaluate the tradeoffs.

Of course, no-one has said that.  Both CONNECT and connection-upgrade are well defined
semantics for tunneling that-which-is-not-HTTP, or that-which-extends-HTTP.  As long
as the conversation retains the basic premises that HTTP is not async/bidi, message
bodies can and will be buffered, etc, then all RFC-conformant solutions should stay
on the table.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Dec 2010 11:04:15 +1100

> It might be worth testing a new port (not 80 or 443 or any other well-known port) for success rate. It would also be worthwhile comparing TLS over port 443. It may be that 443 is the only option th…

+1, although I'd reiterate that defining a new default port would be a nice balance, in that people could still specify 443 in the URL, yet we wouldn't be explicitly promoting the circumvention of firewalls (which IMO isn't going to get past IETF review).

The problem with using port 80 is that it's a catch-22; using it gets you past most firewalls, because it has a well-known protocol on it, but because it has a well-known protocol on it, people interpose devices that make assumptions about the protocol being spoken. We can bend the protocol in lots of ways to try to work around that, but by nature it's going to be inexact and brittle to do so.

---

From: Adam Barth <[email-masked]>
Date: Tue, 7 Dec 2010 16:25:28 -0800

On Mon, Dec 6, 2010 at 11:29 PM, Willy Tarreau <[email-masked]> wrote:
> We have no idea where it was measured.

It was measured on the Internet.  We placed an advertisement on an ad
network containing the experiment.  The ad was shown globally,
according to the audience of the ad network.

> If it's in a campus, 13% of failure is
> was in corporate networks, 13% is low.

The experiment was not designed to measure success rates, so I
wouldn't read too much into them.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 8 Dec 2010 10:28:02 +0100

On 8 December 2010 00:47, Maciej Stachowiak <[email-masked]> wrote:
> The main complaint about CONNECT from server folks seems to be literally a
> question of semantics. There is also the related practical issue of having
> to turn off alerts on CONNECT attempts if you want to serve WebSocket.

Maciej,

While I agree that semantics is an element of the complaints against
CONNECT, I do not think it is the main complaint.

One part of the  technical complaint is that CONNECT is not a method
that should arrive at an origin server and has been the basis of past
attacks.   It is not just a matter of turning off alerts for CONNECTs
arriving in a data centre so that websocket can work, as the concern
would be what other attacks are you opening up on other infrastructure
by allowing connects.   If the inclusion of websocket headers is
sufficient to turn off attack alerts, then we may be re-enabling
classes of attack that have previously been dealt with.

Another complaint of substance with the CONNECT proposal as it has
been made is the bogus host headers, which likewise can break a lot of
existing HTTP infrastructure.

I'm not saying these issues cannot be dealt with, but they also cannot
be dismissed out of hand. We have very senior/experienced people
saying that letting CONNECT requests reach the servers is going to be
a real problem.  We need to address that will a little more rigour
than suggesting we just turn off alerts.

regards

---

From: Zhong Yu <[email-masked]>
Date: Tue, 07 Dec 2010 22:38:46 +0000

On Tue, Dec 7, 2010 at 3:42 AM, Dave Cridland <[email-masked]> wrote:
>> I'd like to see more detail on the data than is found in the paper, but it
>> seems to show a real-world hazard with use of Upgrade, since many
>> intermediaries do not understand it and at least a few are confused into
>> treating subsequent traffic as additional HTTP requests and responses.
>
> The paper shows that many intermediaries treat any traffic as HTTP requests
> and responses until they find a CONNECT, after which they treat the traffic
> as opaque except in a tiny minority of cases (what, 4 out of 54,000?).

I do not think the paper corroborates that argument at all.

Quoting the paper: "In our experiments, we observed two proxies which
appear not to understand CONNECT but simply to treat the request as an
ordinary request and then separately route subsequent requests, with
all routing based on IP address."

Sounds simple and clear, but let's dig a little deeper. The
experiments sent bytes in the following form (as far as we know, from
conversations on this mailing list)

  CONNECT websocket.invalid:443 HTTP/1.1
  Host: websocket.invalid:443
  Sec-WebSocket-Key: <connection-key>
  Sec-WebSocket-Metadata: <metadata>

  GET /script.php/<random> HTTP/1.1
  Host: target.com

that is, two HTTP requests, well formed. An HTTP interceptor that
understands CONNECT will treat the load(all bytes after the connect
request) as opaque and forward them to the server verbatim.

On the other hand, a "CONNECT-agnostic" HTTP interceptor, one that
does not "understand CONNECT but simply to treat the request as an
ordinary request and then separately route subsequent requests, with
all routing based on IP address", will do ... pretty much the same
thing! It could have parsed the load into a HTTP request, then sent
the request to the server as is, effectively forwarding the load to
the server verbatim. Neither the client nor the server could detect
the fact that this interceptor parsed the load as HTTP requests.

Some CONNECT-agnostic interceptors may have touched the 2nd request in
some way, allowing the server to detect them. The two proxies
described in the paper may have done something like that. It would
nice if the authors tell us how exactly they are detected.

Other than that though, how many other interceptors are
CONNECT-agnostic? I don't see how you can even make a wild guess based
on the experiments conducted.

See also my previous inquires about the experiments (yet to be answered)
http://www.ietf.org/mail-archive/web/hybi/current/msg04971.html
http://www.ietf.org/mail-archive/web/hybi/current/msg04972.html

- Zhong Yu

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 12:51:40 +1100

Keep in mind you're e-mailing *two* working group lists here, and those on httpbis may not be aware of the entire discussion that's happened in hybi. 

Having said that, the original question on this thread was about Upgrade, so we've drifted off-topic.

AIUI, the issue of concern with Upgrade is that some intercepting proxies will forward the Upgrade header, despite it being both hop-by-hop in the spec, and listed in the Connection header. Because the proxy would be parsing the traffic as if it were HTTP messages and also routing them, it introduces new attack vectors.

A quick aside for clarification here -- IETF folks have been unhappy with the practice of deploying intercepting proxies for more than a decade, and this is just one of many bad effects they introduce. 

IME one of the primary reasons people deploy them is that proxy configuration by browsers is, at best, primitive. I and many others have repeatedly asked the browser vendors to work with us on improving proxy configuration, but haven't yet made progress. 

In other words, WebSockets is hard to deploy because browsers haven't made it easy to interpose a proxy without user intervention; there are significant shortfalls in terms of capabilities, and huge differences in how browsers handle proxy.pac, etc. If the browser vendors would like to work to improve this so as to avoid this situation in the future, that would be great (and I'm sure we could find folks in the community to help out), but unfortunately that doesn't help us at the moment. 

That having been said, it seems to me that there is not a "fundamental flaw" (as per the original question) in Upgrade per se; there are implementation issues which cause it not to work in some circumstances. No protocol (or format) is perfectly implemented, so this isn't terribly surprising. 

The question is what the impact of those bad implementations are on deploying a particular use of Upgrade. Upgrade can be used in a perfectly safe manner for some applications of HTTP; for example, Subversion, Atompub, and other places where an untrusted script can't touch the bytes. 

WebSockets, of course, does allow an untrusted script to touch the bytes on the wire, and that's the problem. Adam has proposed one way of dealing with this -- by using a non-routable hostname in the request-line, he's hoping to jam any intercepting proxies so that they'll fail early (13% of traffic, in his tests). As he points out, though, this doesn't offer good security in all circumstances, and I suspect there are probably a few other attacks that could leak through this approach.

If you want to run over port 80 -- whether you use Upgrade, CONNECT, or a new WEBSOCKET_PLEASE method -- you have to deal with the possibility that someone will assume that the traffic is HTTP, and not have a perfect implementation of the protocol. At the moment HYBI seems to want perfect security, perfect interoperability and perfect deployment success; I'd suggest that something has to give. 

I'd suggest that if HYBI doesn't want to use another port (still the most obvious and safest solution), you could explore in a number of strategies for mitigating these flaws, while still using HTTP Upgrade. For example:

1) Preclude traffic being mis-interpreted as HTTP messages by:
  a. Encrypting the entire stream (as discussed), or
  b. Encoding the stream (e.g., disallowing newlines in payload, or transmitting them as a replacement character)

2) Assure that WebSockets messages are also valid HTTP messages, but without the constraints of the HTTP message exchange pattern. 

None of these approaches will deal with interoperability problems caused by transparent proxies, but they should mitigate the security issues, as I understand them. 

This is getting longer than I intended, so I'll stop now.

On 09/12/2010, at 10:28 AM, Brian McKelvey wrote:

> Requiring encryption has been proposed and subsequently rejected by the group many, many times now, mostly in the previous discussion on framing.  There were a number of people with use cases that demanded an extremely high throughput, low overhead solution for various reasons.  Can we please stop considering that option to still be even remotely on the table?  Maybe circle back to it as a last resort if we get desperate, but that's not yet.  Until then it waters down the discussion.
> 
> Encryption should be available but not required.  I myself use draft-76 wss:// exclusively on port 443 of my servers (behind STunnel and HAProxy) because of the higher connection success rate.  But I can understand the use cases where it isnt required, and could be problematic.
> 
> Brian
> 
> Sent from my iPhone
> 
> On Dec 7, 2010, at 7:27 AM, Joe Mason <[email-masked]> wrote:
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Dec 2010 04:03:31 +0100

* Mark Nottingham wrote:
>WebSockets, of course, does allow an untrusted script to touch the bytes
>on the wire, and that's the problem. Adam has proposed one way of
>dealing with this -- by using a non-routable hostname in the
>request-line, he's hoping to jam any intercepting proxies so that
>they'll fail early (13% of traffic, in his tests). As he points out,
>though, this doesn't offer good security in all circumstances, and I
>suspect there are probably a few other attacks that could leak through
>this approach.

(This isn't entirely accurate. There are three hosts involved here, one
on the CONNECT line, one in the Host header of the handshake, and one in
the attacker-controlled client->server traffic if the attacker can make
client->server Websocket traffic look like HTTP traffic. If the server
does not understand "CONNECT" and the attacker can control what goes
over the wire, non-routable hostnames are no help. And there are some
other problems.)

>I'd suggest that if HYBI doesn't want to use another port (still the
>most obvious and safest solution), you could explore in a number of
>strategies for mitigating these flaws, while still using HTTP Upgrade.
>For example:

I think the working group has heard all the notable techniques, as you
say if ultimately the browser controls all the bytes, then there is no
risk; if the attacker cannot control bytes that are critical for any
reasonable exploit, such as white space characters, then there is no
plausible risk either; if we do not use ports commonly used for HTTP,
and make initial communication look much unlike HTTP, there is also no
plausible problem. If we never actually leave the HTTP realm, such as
by using chunked encoding with two essentially infinite streams, then
there is also no plausible risk; finally there are the "talisman" pro-
posals, where you send something odd and hope for the best (Ian's "76"
draft has a "send malformed HTTP message" approach, Adam et al. have
the "CONNECT" approach, Dave Cridland suggests sending something that
looks like a CONNECT request but really isn't, and there are some ping
pong hello and goodbye proposals I haven't kept track of; there is a
plausible risk to all of those, but it's far fetched and evidence does
not support that there is a grave concern.

What the Working Group does not have is a framework in which this can
be resolved. If you want sendfile() client->server and server->client
to work and want (within reason) perfect security, then there is no
alternative to a dedicated port. If you want to use port 80 and want
perfect security, then you can only use infinite chunks (although it
is not entirely clear how secure that would be) or escaping/encryption.
And so on. At the moment it seems the working group needs an overview
of the many options that have been offered, or at least a straw poll
to put some metrics behind how important it is to protect against the
various attacks, or accomodate performance or compatibility require-
ments. (Ideally we'd have some numbers along the lines of "If you do
this, then the success rate is that" and so on, but there seem to be
few takers to aid in that.)
-- 
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: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 14:10:59 +1100

On 09/12/2010, at 2:03 PM, Bjoern Hoehrmann wrote:

> be resolved.

Indeed. I think the original question has been answered; we can't help if HYBI doesn't know what it wants. It's clear to me, however, that a) the CONNECT approach isn't a panacea (and indeed may cause more problems than it solves), and b) Upgrade on port 80 is workable, provided that you can accept that not all attempts are successful (a trait shared by any approach on port 80).

Cheers,

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 09 Dec 2010 16:25:01 +1300

just on the topic of making the transfer look like HTTP and use 
"infinite chunks"

I think that would pose serious problems for intermediaries that process 
content (such as border AV systems).

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 14:30:38 +1100

One other thing --

> not support that there is a grave concern.

I still haven't seen anyone explain why CONNECT is better than, say, WEBSOCKET_PLEASE.

Also, from a quick read of the archive, it appears that encoding the stream (e.g., XOR, removing newlines, etc.) was shot down very quickly because people couldn't do sendfile(). 

That makes me wonder: what are the use cases for using sendfile() with WebSockets that can't be addressed by HTTP (more reliably, by everything I've seen here)?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Dec 2010 04:45:29 +0100

>I still haven't seen anyone explain why CONNECT is better than, say, WEBSOCKET_PLEASE.

As I understand it, some people hope that the HTTP framing implied by
"CONNECT" (essentially, anything the client sends after the server does
send it's HTTP response is not interpreted as HTTP traffic) is very
widely implemented, while a WEBSOCKET-specific method might follow a
different code path in deployed implementations, whatever that might
entail (it's common for servers to close the connection if they see a
method they do not recognize, but who knows what the odd server does.)

>Also, from a quick read of the archive, it appears that encoding the
>stream (e.g., XOR, removing newlines, etc.) was shot down very quickly
>because people couldn't do sendfile().

I think there is a rough consensus to do some XOR obfuscation if that
is necessary or helpful, even though some would rather be able to do
the easy sendfile() call instead, but the benefits are not very clear
(if the attacker learns or can predict the XOR key, you've not gained
much, in some scenarios anyway.)

>That makes me wonder: what are the use cases for using sendfile() with
>WebSockets that can't be addressed by HTTP (more reliably, by everything
>I've seen here)?

(I think the question would be more aptly put as an issue of "you can
do this using simple commands to the hardware" versus "you have to
pump everything through the main processor"; while static files would
be a good example, you could also imagine, say, a camera that offers a
"WebM" stream you'd like to direct directly at the network equipment.)
-- 
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: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 14:55:56 +1100

> method they do not recognize, but who knows what the odd server does.)

CONNECT to a server (intermediary or origin) that isn't expecting it can and will be treated like any other method that isn't understood -- it's perfectly legitimate for a server to generate a 405 Method Not Allowed.  As such, using CONNECT isn't a guarantee that the message framing has changed on the request, until the server agrees to its semantics. Given that those semantics are specific to configured proxies, and an intermediary "agrees" by forwarding the message even when it doesn't understand its semantics, this is indeed an entirely hope-based assumption; that every intermediary (firewalls, virus scanners, caching proxies) is built to understand CONNECT, even when many of them can't be configured as an explicit proxy at all. 

> much, in some scenarios anyway.)

I was thinking more about stripping newlines, etc., but yes, it's more expensive. Just not sure why that's an issue, which is why I asked...

> "WebM" stream you'd like to direct directly at the network equipment.)

I see. I still wonder, given that HTTP streaming is evolving pretty fast, and realtime streaming requires UDP, not TCP.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 17:09:40 +1100

On 09/12/2010, at 4:45 PM, John Tamplin wrote:
> 
> Adam's experiment found cases where transparent intermediaries did not
> treat GET+Upgrade as any different from GET (and therefore the following
> frames were interpreted as HTTP), while they found none that treated
> frames exchanged after a successful CONNECT as if they were HTTP.

Adam's experiment was a bit more than 50,000 requests. That's hardly conclusive.

>> As such, using CONNECT isn't a guarantee that the message framing
>> has changed on the request, until the server agrees to its semantics.
>> Given that those semantics are specific to configured proxies, and an
>> intermediary "agrees" by forwarding the message even when it doesn't
>> understand its semantics, this is indeed an entirely hope-based
>> assumption; that every intermediary (firewalls, virus scanners, caching
>> proxies) is built to understand CONNECT, even when many of them
>> can't be configured as an explicit proxy at all.
> 
> Transparent intermediaries are by definition not configured into the browser.
> They don't know what the browser is actually connecting to when they
> view and possibly intercept the presumed HTTP traffic.  As such, they
> already have to be written to assume the browser might in fact be
> connecting to a non-transparent proxy, so the presence of a CONNECT
> method should not be unexpected.

You're basically asserting that the security of WebSockets relies on all vendors of intercepting proxies implementing to meet this use case. 

>> I was thinking more about stripping newlines, etc., but yes, it's more
>> expensive. Just not sure why that's an issue, which is why I asked...
> 
> Some people worry about servers that have to terminate a very large
> number of WebSocket connections, so the memory and CPU
> requirements do matter.
> 
> I think stripping newlines or padding is more expensive to overall
> performance than doing XOR or encryption, since the number of
> bytes change and now you have to make a second pass through
> the frame to get the correct length, or require the reader to do it a
> byte at a time.
> 
> At least XOR with a per-frame key adds a fixed number of bytes,
> so you can just add that to the frame length received from the
> upper layer.

That makes sense.

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 08 Dec 2010 22:21:23 -0800

On Dec 8, 2010, at 8:10 PM, Jack Moffitt wrote:

> One path is to combine the separate port idea along with the
> encryption based approach. On the WebSocket port, you could avoid all
> the intermediary issues, but perhaps be limited by firewalls.
> However, you would not need any obfuscation and could easily use
> sendfile().  On the TLS port you use NPN to get a WebSocket that is
> not going to cause security problems with intermediaries.
> 
> For the short term, we get WebSocket on the port with the highest
> success rate, and in the long term, we have firewalls accepting the
> new port as killer applications make people care.
> 
> If we're going to lose the sendfile(), why not go the rest of the way?
> Or is there something I'm missing in the port 80 but just XORed case?

If the attacker can choose an arbitrary port to connect to, then you still need some form of obfuscation or attempt to avoid looking like valid HTTP, since they could chose port 80, 8080, 8000, or other ports not infrequently used for HTTP.

Regards,
Maciej

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 09 Dec 2010 04:11:29 +0000

jack.

---

From: John Tamplin <[email-masked]>
Date: Thu, 09 Dec 2010 05:46:19 +0000

On Wed, Dec 8, 2010 at 10:55 PM, Mark Nottingham <[email-masked]> wrote:
> CONNECT to a server (intermediary or origin) that isn't expecting it can
> and will be treated like any other method that isn't understood -- it's
> perfectly legitimate for a server to generate a 405 Method Not Allowed.

Sure, and in such a case no WebSocket frames will be sent on the
connection and no attack can take place.

That doesn't mean that such intermediaries do not exist, but it does seem
to indicate that CONNECT is stronger than GET+Upgrade regarding
confusing transparent intermediaries.

If the destination server is not a WebSocket server, then it will not pass
the handshake test and therefore no WebSocket frames will transit the
intermediary.

---

From: Collin Jackson <[email-masked]>
Date: Thu, 9 Dec 2010 00:38:02 -0800

On Sat, 4 Dec 2010 2:50 PM, Zhong Yu <[email-masked]> wrote:
> So in the POST experiment, the bytes are
>
>     POST /path/of/attackers/choice HTTP/1.1
>     Host: host-of-attackers-choice.com
> In 1376 cases the 2nd request was routed to target.com, presumably
> because some interceptors parsed it as an HTTP request, and routed it
> based on Host.
>
> In the Upgrade experiment, the bytes are
>
>     GET /path/of/attackers/choice HTTP/1.1
>     Host: host-of-attackers-choice.com
>     Connection: Upgrade
>     Upgrade: WebSocket
> In only 1 case the 2nd request was routed to target.com. This
> experiment is apparently done in the same ad display as the POST
> experiment, and the bytes passed over same intermediaries.
>
> Don't you find that odd? How do you explain the difference?

My interpretation is that most (but not all) of the proxies that route
requests by Host header decided not to parse the 2nd request as an
HTTP request, because they observed an HTTP Upgrade negotiation in the
first request.

On Sat, 4 Dec 2010 at 3:39 PM, Zhong Yu <[email-masked]> wrote:
> From paper: "47,741 (96:9%) reported that no intermediaries were
> confused when sending the spoofed HTTP request"
>
> What's the expected behavior here? The 2nd request is transmitted to
> host-of-attackers-choice.com verbatim, right?
>
> "There were 97 of 49;218 impressions (0:2%) where the spoofed request
> was routed by IP"
>
> The 2nd request is also transmitted to host-of-attackers-choice.com
> verbatim, right? How does this differ from the 1st case?

The 2nd request was received by the server on a separate network connection.

> nice if the authors tell us how exactly they are detected.

The 2nd request was transmitted on a separate network connection. That
is how we distinguished it from the normal case, which re-uses the
initial connection.

As discussed in Section V(C)(3) of the paper, we did not observe any
caching proxies that had this behavior in our experiment. If these
proxies are a concern, it is possible to prevent them from becoming
poisoned using encryption.

Collin Jackson

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2010 20:53:57 +1100

> confusing transparent intermediaries.

Again, it's completely apples and oranges. Those requests failed because an unroutable message was sent, not because of any magical properties of CONNECT.

Regards,