Subject: [hybi] Shipping WebSockets

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

I was asked to jot down a few thoughts about the current state of the WebSockets handshake discussion, with an eye to making progress. FWIW:

* What we can Learn from the CONNECT Experiment

Many are focusing on the CONNECT-based handshake proposed by Adam, because his study shows flaws in the existing Upgrade-based handshake.

It's reasonable to think, then, that we should move to a CONNECT-based handshake, but this assumption is incorrect -- because Adam varied the handshake in several dimensions:

1) request method (POST vs. CONNECT)
2) request headers (Upgrade vs. none)
3) target URI (valid vs. invalid)

The study showed that changing all three aspects of the request improved security in a fairly small sample (50,000 requests), but it didn't show *which* factor(s) affected security.

I strongly suspect that ALL of the improvement seen in the study can be attributed to (3), because proxies configured to route on the Host header will not be able to forward the message; effectively, this message "jams" insecure interception proxies. 

* Overloading CONNECT and HTTP Conformance

Because people believe that some interception proxies will treat CONNECT differently, it's still reasonable to think that it'd be advantageous to use CONNECT anyway, on the theory that "it can't hurt."

However, using CONNECT in this way is not in keeping with the semantics of CONNECT (despite assertions to the contrary, no matter how often repeated). A box that isn't expecting CONNECT does not have to treat it differently to any other HTTP request, and if that box is an intermediary, that includes forwarding it or erroring.

As such, this is breaking the contract of HTTP, in that implementations can't be expected to behave in a uniform or predictable fashion when handling the handshake message. No matter how many experiments are run, there are still potentially implementations that will handle the handshake in a dangerous way, because the people implementing that software had no expectation of this type of message coming through.

In other words, using the CONNECT handshake is equivalent to running a non-HTTP (even binary) protocol over port 80. It's clear that the authors have suggested CONNECT in an attempt to claim HTTP conformance, thus working around the declared consensus for that in HYBI. However, I'd argue that if we're going to run a non-HTTP protocol over port 80 (a subject still worthy of discussion; see below), it should NOT look like an existing HTTP message.

* Dealing with Injection Attacks

As Adam notes in the paper, it's still possible -- with or without the CONNECT handshake -- to inject messages in such a way as to trick interception proxies into believing that they're HTTP messages. It may be that some such proxies will treat CONNECT as a request for an opaque tunnel, but this is by no means guaranteed, because CONNECT is not specified for use in cases where there is not an explicitly transparent proxy, and interception proxies are not specified at all.

As such, to meet a high bar for security (which seems to be applied elsewhere in WebSockets design), it's necessary to disallow such injection. There are three ways to do this:

A) by making it impossible to inject an HTTP response -- e.g., encoding or disallowing newlines; encrypting the stream
B) by framing all WebSockets messages (not just the handshake) as HTTP messages -- so that any interception proxy can't be tricked into routing based upon attacker-controlled content
C) by not allowing WebSockets on ports where HTTP is spoken

* Ports and Security

It's clear that making WebSockets safe for transit over port 80 is non-trivial. The arguments for allowing it over port 80 are mostly centred on its well-known ability to transit firewalls and other forms of port blocking.

First, it's important to acknowledge the paradox of this approach. We're saying that we want to maximise our chances of success by reusing a port where we know there is a large amount of existing, non-compatible traffic, and that often that traffic is intercepted in ways that are not compatible with the new application.

While it's true that some network administrators block ports other than 80 routinely now, it does not follow that, when demanded by their users and deemed secure, they will always be blocked. The logic behind that argument would have prevented the Web itself (or any other new application) ever being deployed successfully.

Reusing port 80 as the default port for WebSockets, even though the nature of the traffic is significantly different, is extremely hostile to firewall administrators. Some will selectively block WebSockets traffic based upon a signature, and will eventually deploy software that intercepts and inspects WebSockets traffic, just as is done for HTTP today.

Given that the IETF represents not only the browser vendors and server-side application developers, but also the network operators and vendors for network hardware and software, I question whether it's prudent to effectively lie to ourselves; to run non-HTTP traffic over the HTTP port, in the name of expedience, when in the long term, the result will be the same -- sites that want to block WebSockets traffic will, and sites that want to offer the improved services that WebSockets promises will allow it.

It might be argued that deploying WebSockets with a default port other than 80 will hurt adoption, risking the effort (especially since Comet is already available). I don't find this a convincing argument, since deploying WebSockets on port 80 won't guarantee availability either; as discussed above, interception proxies (and likely stateful firewalls as well) will block a significant portion of the traffic.

* Proposed Approaches

With all of this in mind, I think the following approaches are viable, in order of preference:

1) Define a default high port for WS, disallow it on port 80, allow it on 443. Measures for counteracting interception proxies should be unnecessary (and the handshake can look however we like), it's possible to use as log as 443 is available, and we can get on with our lives.

2) Define a default high port for WS, allow it on 80, 443 and perhaps other ports. Then, define a handshake that doesn't look remotely like HTTP; e..g, 

START * WEBSOCKET/1.0

3) Define a default high port for WS, allow it on 80, 443 and perhaps other ports. Then, define a handshake that isn't routable by using an invalid address + a new method; e.g.,

WEBSOCKET_PLEASE websocket.invalid HTTP/1.1
Host: websocket.invalid

* Making a Decision

I agree that this WG can't make forward progress until it has a framework for making a decision.

To my eye, the most relevant factors to discuss are:

a) Security -- How secure does the result have to be, and how do we define it? How do we measure success?
b) Availability -- How tolerable is failure to get a connection? How do we measure this? When is it acceptable to fail?

I do NOT think this group should spend much more time on internal discussion of which handshake is HTTP compliant, what the appropriate (re-)use of a port is, etc. Ultimately, those judgements will be made by the IETF as a whole, so time would be better spent working with the rest of the organisation, rather than coming up with a solution that might not get through the process.

Regards,

--
Mark Nottingham   http://www.mnot.net/   (Chair, HTTPbis WG / Contributor, Squid and Node.JS)

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 14 Dec 2010 16:33:32 -0800

I think a few premises in your message are wrong, and therefore your proposed courses of action are not suitable options for the group.

> I strongly suspect that ALL of the improvement seen in the study can be attributed to (3), because proxies configured to route on the Host header will not be able to forward the message; effectivel…

I think your suspicion is wrong. I think CONNECT was effective at preventing cache poisoning attacks because proxies stop interpreting the stream as requests when they see a CONNECT. A GET with a URI pointing to an invalid host would almost certainly fail in the exact way tested.

[snip]

> C) by not allowing WebSockets on ports where HTTP is spoken

There are Web services that run on ports besides 80. While there are much fewer of them, I think it's still important to protect them from novel attack vectors. Blocking port 80 is a naiive approach to defending against cross-protocol attacks.

[snip]

> 1) Define a default high port for WS, disallow it on port 80, allow it on 443. Measures for counteracting interception proxies should be unnecessary (and the handshake can look however we like), it…

This does not fix the security issues. "Disallow on port 80" is not sufficient to protect against all the various cross-protocol threat models. Web servers can and often do on non-80 ports. We would also need to design a handshake that is safely usable on port 443.

> 2) Define a default high port for WS, allow it on 80, 443 and perhaps other ports. Then, define a handshake that doesn't look remotely like HTTP; e..g, 

If you start with ASCII, it's highly likely there will be a way that origin servers or intermediaries can be confused. The history of cross-protocol attacks shows that such heuristic defenses are ineffective.

> WEBSOCKET_PLEASE websocket.invalid HTTP/1.1

This is likely to be ineffective at defending against the attack identified by Adam et al in their paper, since the key measure that stops subsequent content from being interpreted as further requests is the use of CONNECT, not the use of an invalid host.

I think the following option, which you may or may not like, is likely to viably address the security issues:

4) Always use TLS for WebSocket connections, using an NPN-based handshake. Define two URI schemes, wss:, which uses full TLS and expects a proper server cert, and ws:, for which we define some variant where it's not required to have a properly issued valid cert.

This doesn't introduce new attack vectors, because:
    (a) Browsers already have the ability to attempt a TLS connection to any port, so there's no new exposure for non-HTTPS servers. They must already be secure against this.
    (b) Existing TLS servers that are not upgraded to NPN will fail the connection.
    (c) TLS servers upgraded to use NPN can dispatch early between WebSocket protocol and HTTP, so HTTP infrastructure past the TLS termination point won't get confused.
    (d) Intermediaries will be unable to read the traffic and therefore won't be confused by it.

The main downside to this approach, compared to the CONNECT handshake, is performance, on both client and server side.

Also, you could ask whether this violates the definition of port 443 in some abstract sense, in the same way that CONNECT arguably violates the definition of port 80.

> I do NOT think this group should spend much more time on internal discussion of which handshake is HTTP compliant, what the appropriate (re-)use of a port is, etc. Ultimately, those judgements will…

Somebody has to decide whether the IETF as a whole is likely to consider the handshake as HTTP compliant. If the WG doesn't make a provisional judgment, what should we do instead? Throw something out there and hope the IETF likes it? Surely someone needs to decide whether a proposal is likely to succeed.

Regards,
Maciej

---

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

> I think your suspicion is wrong. I think CONNECT was effective at preventing cache poisoning attacks because proxies stop interpreting the stream as requests when they see a CONNECT. A GET with a U…

I tested intercepting proxy behaviour before stating a position; did you?

> There are Web services that run on ports besides 80. While there are much fewer of them, I think it's still important to protect them from novel attack vectors. Blocking port 80 is a naiive approac…

Note I said 'ports'; e.g., by blocking all but a designated high port, or (with less security) by blocking low ports. Are you asserting that people intercept ports other than 80 and assume that the traffic is HTTP? Can you substantiate it?

> This does not fix the security issues. "Disallow on port 80" is not sufficient to protect against all the various cross-protocol threat models. Web servers can and often do on non-80 ports. We woul…

See above.

> If you start with ASCII, it's highly likely there will be a way that origin servers or intermediaries can be confused. The history of cross-protocol attacks shows that such heuristic defenses are i…

Please substantiate "highly likely." And, if this WG is so sensitive to confusing common deployments and encountering the associated problems, I have to ask again -- why are you even considering allowing this protocol to run over port 80, where the majority of these problems happen?

> This is likely to be ineffective at defending against the attack identified by Adam et al in their paper, since the key measure that stops subsequent content from being interpreted as further reque…

See above. If you continue to believe that CONNECT is magical, it's going to be difficult to move forward.

> The main downside to this approach, compared to the CONNECT handshake, is performance, on both client and server side.

I'm fine with it, but I suspect others may not be. Happy to be surprised here.

> Also, you could ask whether this violates the definition of port 443 in some abstract sense, in the same way that CONNECT arguably violates the definition of port 80.

Some might argue that; I'm not one of them. There are two practical differences:

1) the application payload on 443 is by nature opaque, so there's much less meddling with it, and
2) the SSL/TLS handshake is much less sloppy / more brittle than HTTP's, so it's easier to assure that you're not talking SSL/TLS and therefore worry about injection.

> Somebody has to decide whether the IETF as a whole is likely to consider the handshake as HTTP compliant. If the WG doesn't make a provisional judgment, what should we do instead? Throw something o…

All I'm saying here is that the group should not spend too much time second-guessing what the rest of the community will do; rather, it should formulate a proposal quickly and ask for wider review.

Regards,

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 14 Dec 2010 18:16:22 -0800

> I tested intercepting proxy behaviour before stating a position; did you?

No, my argument is theoretical considerations. If you have some data to share, I'd be glad to review it.

> Note I said 'ports'; e.g., by blocking all but a designated high port, or (with less security) by blocking low ports. Are you asserting that people intercept ports other than 80 and assume that the…

There are cross-protocol security risks other than interception by a transparent proxy, including against origin servers or virtual hosting setups. You can't assume non-80

Removing the choice of port entirely would probably remove the risk to existing servers with fairly high likelihood, but would also cripple deployment. I'm not super interested in shipping a WebSockets protocol that won't be used.

>> This does not fix the security issues. "Disallow on port 80" is not sufficient to protect against all the various cross-protocol threat models. Web servers can and often do on non-80 ports. We wou…

If the design is port 443-only, but using a readable protocol instead of TLS, we'd still have to do some work to avoid putting intermediaries at risk. 

> Please substantiate "highly likely."

There is a long history of HTTP being used to attack servers of other protocols. As a result, browsers have added port blocking over time to patch most of the problem. Reviewing the history says to me that a text-based protocol which isn't explicitly designed to be quickly rejected by other servers, or else categorically unable to send commands they can process, is likely to eventually be used for cross-protocol attacks.

> And, if this WG is so sensitive to confusing common deployments and encountering the associated problems, I have to ask again -- why are you even considering allowing this protocol to run over port 80, where the majority of these problems happen?

If we can find a viable design that won't lead to cross-protocol attacks, the potential payoff is high. Personally, I think TLS-only over port 443 is a high enough payoff.

> 2) the SSL/TLS handshake is much less sloppy / more brittle than HTTP's, so it's easier to assure that you're not talking SSL/TLS and therefore worry about injection.

That seems like a pragmatic difference, not a matter of principle. I agree that in TLS-land things are simpler. But I also think CONNECT + invalid host + payload masking is a pretty good solution to the practical problems, and the remaining objections being made are ones of principle.

> All I'm saying here is that the group should not spend too much time second-guessing what the rest of the community will do; rather, it should formulate a proposal quickly and ask for wider review.

Sounds reasonable, though at this point, I'm not sure we are close to WG consensus even if we ignore what the rest of the IETF is likely to think.

Regards,
Maciej

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Dec 2010 03:20:56 +0100

* Maciej Stachowiak wrote:
>I think your suspicion is wrong. I think CONNECT was effective at
>preventing cache poisoning attacks because proxies stop interpreting the
>stream as requests when they see a CONNECT. A GET with a URI pointing to
>an invalid host would almost certainly fail in the exact way tested.

What struck me in this discussion is that there seems to be quite a bit
of overlap among the people who rejected arguments along the lines of
"We can assume such and such from reasonable implementations and could
conduct some tests to make sure" saying implementations do all sorts of
crazy things and testing tells you very little (they want something
provably secure instead) -- and the people easily swayed by that exact
same argument and same ad-hoc testing with respect to "CONNECT".

If you go to RFC 2616 and read up on how you determine the boundaries of
HTTP messages you will find no mention of "If the request was CONNECT
and the server sent a 200 response, the next request isn't really a new
request" and I have seen and written myself quite a bit of software that
does not do interpret "CONNECT" in a special manner (in fact, there is
probably no software at all that implements this part of RFC 2616 exact-
ly as specified, whether that is due to multipart/byteranges processing,
integer overflows, mishandling non-hexdigits in the TE encoding, etc.)

It's clear that "CONNECT" doesn't jibe all that well with HTTP, and it
is clear that any solution that is (within reason) provably secure will
not depend on on "CONNECT", so we would end up with "CONNECT" only if we
agree that wishful-thinking-security is good enough (realizing of course
that some wishes are more realistic than others, but they'd be wishes
all the same, there just isn't anything other than assumptions and some
testing that tells CONNECT and other methods apart).
-- 
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: Zhong Yu <[email-masked]>
Date: Tue, 14 Dec 2010 20:23:13 -0600

I find most of your points refreshing, but first, I'm compelled to
bust the myth that Adam Barth's experiments demonstrated insecurity in
the GET+Upgrade protocol.

In these experiments, two valid HTTP requests are sent on the wire.
For any component which targets HTTP traffic, it MUST recognize them
as two valid HTTP requests, because they are two valid HTTP requests.

The experiments did not test the proposed GET+Upgrade protocol, which
contains bytes that will choke almost all HTTP parsers. The real
GET+Upgrade protocol would not have triggered the cache poisoning
attack - at least, there is not data suggesting that.

They claim that the experiments gave empirical evidence that
GET+Upgrade is prune to be employed to exploit the flaws in HTTP
interceptors. That claim is utterly false.

This "paper" - let me be as polite as I can ever be - contains very
little proof to what it supposed to prove, and many people on this
mailing list granted benefit of doubt to conclusions that don't
deserve it.

- Zhong Yu

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 15 Dec 2010 06:58:39 +0100

Hi Mark,

below a few complements.

> WEBSOCKET_PLEASE websocket.invalid HTTP/1.1

4) use HTTP upgrade and avoid LFs in response and be happy with HTTP and WS
side by side whatever the port.

Also, I'm still amazed that some people find this solution complex while at
the same time there is so much pressure to use TLS which is more complex to
use, expensive in terms of performance, prevents any form of analysis in
intermediaries (eg: parental control, schools), and can prevent routing
information from being used, thus voiding all hopes of deployment in shared
hosting environments.

> b) Availability -- How tolerable is failure to get a connection? How do we measure this? When is it acceptable to fail?

c) Adoption -- what constraints do we impose on adopters, will they be willing
to accept them. Eg: lack of routing info == one IP per customer when millions
of web sites can run over the same IP.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 15 Dec 2010 07:23:08 +0100

> No, my argument is theoretical considerations. If you have some data to share, I'd be glad to review it.

Just after a quick look, the nginx code does not know the CONNECT method,
still it supports a caching reverse-proxy. Eventhough that's probably not
the case for it, we could fairly imagine that if such a proxy receives a
CONNECT request to which it receives a 200, it could cache the response.

Also the problem of supporting CONNECT on interception proxies remains.
For instance, at a customer's a squid is used as an interception proxy.
It makes use of the Host field to forward the request. However, if I
declare its address as an explicit proxy in my browser, it works perfectly,
including the CONNECT requests. That means that such an interception proxy
will unexpectedly decode the request instead of forwarding it. From now on,
we already know that everyone using squid as an interception proxy will see
websocket fail in a way that is not necessarily easy to fix in the code
(especially when the proxy does not know the original destination address).
At least the routable upgrade-based mechanism could be made to work within
a few hours by implementing it into the code.

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Dec 2010 09:39:09 +0100

I think we are getting no where because we are entirely focused on the
points of disagreement.

Why not focus on what we do agree on?

Does anybody object to flipping the MORE bit to a FIN bit?  this gives
us framing that is less likely to be seen as a HTTP request/response.

Does anybody object to wrapping the nonce/hash bytes sent after the
handshake requests as HELLO frames?  This means that implementations
only need to deal with 2 framing mechanisms not 3.

Does anybody object to sending the nonce/hash from the server first
and then from the client?   This fixes the long standing bug with the
-76 handshake that blocks intermediaries that would otherwise work.
It does not need an extra round trip to give the same degree of nonce
checking that -76 has?  This makes the handshake HTTP compliant and no
non-HTTP data is sent until after client and server have agreed on the
new protocol.

Does anybody object to simple hex encoding of nonces and hashes?

Does anybody object to adding a server nonce?

If we can agree on these things, then some progress will have been
made.   We will then have a more robust handshake in which we can
test:

a) GET+Upgrade vs WEBSOCKET+Upgrade vs CONNECT (and why not CONNECT+Upgrade?)
b) valid Host vs invalid Host

etc.

Until we make progress on the simple things, then any comparison of a
new proposal against the existing handshake is going to be meet with
the apples vs oranges argument - Ie we have not actually tested if
CONNECT is better because too many other things were changes etc. etc.
      Some might argue this is not a valid defence, but that still
doesn't get us any progress.

The style of decision making is too much all-or-nothing and
winner-takes-all.   There is no reason we have to adopt an entire
handshake proposal with all it's features - that's what we did with
-76 and look at the mess we are in.   Let's incrementally improve to
the point we can isolate the contentious issues such as CONNECT vs
Upgrade and then we can test those and discuss them without
distractions.

regards

---

From: Zhong Yu <[email-masked]>
Date: Wed, 15 Dec 2010 05:21:56 -0600

I'm leaning towards a distinct, non-HTTP approach, with some HTTP
resemblance conservatively and carefully added to it. My proposal will
be somewhere close to Mark's approach #2 and #3.

>From a purist's stand, WS should be distinct. It should not be easily
confused as HTTP(or other protocols) by existing or future programs.

However there are strong pressures to have *some* HTTP-ness in WS.
People want some existing HTTP components to work with WS with no(or
little) modification. People want to keep some HTTP features in WS
without reinventing an alien syntax.

An apparent answer to these demands is to make WS looks almost like
HTTP, even make it 100% HTTP compliant. This answer is not only over
reaching, but also improbable to achieve.

A) It's over reaching because only *some* specific HTTP-ness were
demanded, not *all*. They are specific and few in number. We could
conservatively approve these specific demands, make room for them in
the protocol, while keeping the overall syntax distinctly non-HTTP.

B) It is improbable to achieve, because there is no room in HTTP space
that WS can be accommodated.

1)  Upgrade - if it's rarely implemented, it practically doesn't
exist. GET+Upgrade will be treated by most as simple HTTP GET. If WS
depends on "Upgrade", WS is basically imposing a new HTTP feature on
existing HTTP infrastructure(i.e. expanding HTTP space). This will
even affect systems that don't want anything to do with WS. "Upgrade"
protocol would be deployed under the clear knowledge that it's going
to confuse the heck of a lot of HTTP programs. It would be
sanctimonious for us to blame these programs for misunderstanding the
new protocol, meanwhile arguing in straight face that WS is innocent
of causing the trouble.

2) CONNECT - semantically incorrect. Willy Tarreau just showed a real
example why overloading CONNECT is confusing at the least. Some may
argue that CONNECT semantics isn't so strict that it excludes the
possibility of being used for WS. That is being too lawyerly, ignoring
people's commonly accepted view. If CONNECT semantics is indeed muddy,
WS should not add even more confusion to it.

3) other tricks like placing WS in HTTP request/response bodies(that
are infinitely large). Such tricks are simply against the nature of
HTTP, WS messaging model simply doesn't fit in HTTP messaging scheme.
There is no way to make it work reliably over typical HTTP components.

After showing that it's improbable to fit WS in HTTP space, I'll argue
that it is inappropriate to do so. The latter is far more important in
my opinion, yet I fear raising it first won't get much attention. It
is inappropriate because it is to intentionally exploit weakness of,
inflict confusion upon, and defeat the purpose of many current HTTP
components. It is a lie, as Mark put it, to pretend that WS is HTTP.

==

Here's my attempt at what WS can look like. It's distinctly non-HTTP,
with some HTTP-ness that are demanded to be included in WS.

----
  WebSocket WebSocket WebSocket
  Uri: ws://example.com/path
  Origin: foo.com
  Sec-WebSocket-XX : ...
  ...
  Host: example.com
  Cookie: sessionid=s92Afw23hh ...

  <client HELLO frame>
----
  WebSocket 200 OK
  Sec-WebSocket-XX : ...

  <server HELLO frame>
----

There is intentional resemblance of HTTP syntax at some lower level.
There are 3 tokens in the first line. Header lines are simplified
subset of HTTP header lines. There is a blank line between headers and
the first frame.

A HTTP parser will likely accept this syntax at some lower level. If
not, it probably rejects one or more tokens on the first line. If this
parser is asked to be modified to accept WS, code change at this level
is likely minimum and non-intrusive.

The syntax is still distinctly non-HTTP because of the first 3 tokens.
It's unlikely to be mistaken as HTTP by current and future programs.
Most current HTTP programs, if they blatantly ignore the HTTP-Version
token, require understanding of the HTTP Method token to perform their
jobs. "WebSocket" in that place will prevent them from doing anything
wrong. If a HTTP program is asked to be modified to handle WS
semantics, code change at this level is likely minimum and
non-intrusive - accept WS "method"/"version" tokens and branch cleanly
for WS logic.

The HELLO frames further reinforce the fact that WS is not HTTP. If
HELLO exchange is successful, we are very confident that further WS
frames will transmit smoothly.

The syntax is designed to fail most HTTP-only components, rightfully.
On the other hand, it is easy, syntactically, to upgrade HTTP
components to incorporate WS handling.

It's unlikely that an HTTP-only component could change the headers -
it must first understand the connection as HTTP, which is unlikely.
Therefore we can assume that the headers stay intact, our protocol can
depend on a simpler header syntax than HTTP's. Although this
simplification might not be interesting if most WS implementation
reuses HTTP parser anyway.

The "Cookie" header is semantically same as HTTP's, by popular demand.

The "Host" and "Cookie" headers are used by virtual hosts and load
balancers to dispatch connections, by popular demand. Note that if a
dispatcher is strict about HTTP, it will fail WS connections,
rightfully. However it is easy to modify them to accept WS connections
and dispatch them in the same way HTTP connections are dispatched.

Ports: WS and WSS should have their designated ports, just for being
different from HTTP. Officially, WS recommends *against* the practice
of reusing HTTP ports. However, we shouldn't forbid 80 and 443. There
is a popular demand to reuse HTTP ports, we leave it as an opt-in. The
decision is shifted to app deployers - if they decide that 80 and 443
work best for their apps, so be it. As long as they are aware that
they are making a moral call as this can cause confusion to the
networks of their users.

Since 80 and 443 are not banned, it's a possible evolution path that
in the end every WS app uses 80/443, the designated ports are
forgotten. Evolution beats design, what can we do. In such scenario,
systems that want to distinguish WS and HTTP traffic will have to
inspect bytes. Fortunately WS syntax is distinct, therefore inspection
is easy - just check first few bytes.

- Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Wed, 15 Dec 2010 05:56:27 -0600

> Does anybody object to sending the nonce/hash from the server first

(just for the record I objected to it. see thread of
http://www.ietf.org/mail-archive/web/hybi/current/msg04710.html
however I don't want to argue about it at this point. We are too
easily distracted from the main course.)

---

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Wed, 15 Dec 2010 11:28:46 -0500

> interceptors. That claim is utterly false.

What I think the paper shows well is that the GET+Upgrade handshake does
not succeed in its purpose of identifying non-websockets aware
intermediaries in the path.

In such a scenario it is plausible that the user data exchange part of
the protocol could be vulnerable to attacks such as the cache poisoning
one described in the paper, but that is not confirmed by the paper.

Nonetheless, it is the purpose of the handshake to establish the
clean-path pre-requisite for the regular message exchange portion of the
session and having failed to do so it makes sense to assume such an
exploit is possible and look for ways to fix the handshake (or change
its goal?).

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

---

From: John Tamplin <[email-masked]>
Date: Wed, 15 Dec 2010 11:44:17 -0500

> us framing that is less likely to be seen as a HTTP request/response.

I don't object to it, but I don't think it helps.  The attacker could
just as easily arrange for the message to be fragmented (assuming any
browser does fragment, which seems likely on a compressed connection,
though that makes it a bit harder to get your chosen plaintext in the
stream), so flipping the bit doesn't actually accomplish anything.

> only need to deal with 2 framing mechanisms not 3.

In the absence of information about the rest of the handshake, yes.
All else being equal, I would prefer they be included in headers.

I don't understand what you mean about 2 framing mechanisms instead of 3 though.

> Does anybody object to simple hex encoding of nonces and hashes?

I wouldn't block it, but base64 seems better and sufficient.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Dec 2010 17:54:07 +0100

On 15 December 2010 17:28, Pat McManus @Mozilla <[email-masked]> wrote:
> session

Strictly speaking, in the design of the -76 handshake it is the HTTP
upgrade plus the unframed random bytes that follow that are to
establish the clear path.  It is proposed that we replace the random
bytes with Hello frames, but the intent remains the same - to
establish that a clear path exists.

The Hello frames are not that thin a defence if we consider the range
of intermediaries:

Some intermediaries are going to be dumb bit forwarders - they are not
vulnerable.
Some intermediaries try to track HTTP framing. of these:
  + some will explicitly support websocket
  + some will specifically support Upgrade
  + some will correctly implement Connection and thus not pass on
Upgrade unless it is supported.
  + some will ignore Connection headers, of these:
    * some will break on the following hello frame
    * it is suggested that some might skip over the hello frame an
reacquire HTTP framing from the content.  Of these:
      # some will not be vulnerable to cache poisoning
      # same may be vulnerable to cache poisoning

We need to stop comparing CONNECT to GET+Upgrade.  The comparison
should be with GET+Upgrade+Hello.      Now it may be that the Hello
defence is still to thin to be acceptable, but I really don't see how
we are going to show that the existence of transparent intermediaries
that track HTTP framing and do not respect the Connection header and
skip non-ascii methods and caches and have a bug that makes them
vulnerable to cache poisoning, is significantly larger than
transparent intermediaries that track HTTP framing and do not handle
the CONNECT method and have caches and have a bug that makes them
vulnerable to cache poisoning.

I don't think one is a clear winner over the other.  But we have to
stop letting the choice between them stop all other progress.

regards

---

From: Andrew Miadowicz <[email-masked]>
Date: Wed, 15 Dec 2010 17:00:40 +0000

The FIN bit works in conjunction with two other requirements:
1. The first WebSocket frame sent by the client MUST be the HELLO frame (as proposed by Greg).
2. Control frames MUST not be fragmented (as stated in the 03 draft).

Because the proposed HELLO frame IS a control frame, it cannot be fragmented, and therefore it is guaranteed to have the FIN bit set.  This in turn means that the first message (post Upgrade exchange) from the client begins with a non-ASCII character, which presumably will trip the majority of transparent proxies that attempt to parse it as the next HTTP request.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tamplin
Sent: Wednesday, December 15, 2010 8:44 AM
To: Greg Wilkins
Cc: [email-masked] HTTP
Subject: Re: [hybi] Shipping WebSockets

> us framing that is less likely to be seen as a HTTP request/response.

I don't object to it, but I don't think it helps.  The attacker could just as easily arrange for the message to be fragmented (assuming any browser does fragment, which seems likely on a compressed connection, though that makes it a bit harder to get your chosen plaintext in the stream), so flipping the bit doesn't actually accomplish anything.

--
John A. Tamplin
Software Engineer (GWT), Google
_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Dec 2010 18:03:22 +0100

> All else being equal, I would prefer they be included in headers.

Well I would not argue with them being headers either.

> I don't understand what you mean about 2 framing mechanisms instead of 3 though.

The connection opens, you first have to parse HTTP.  You then have to
parse 8 bytes.  You then parse websocket packets.

Sure that is trivial if you are writing a blocking implementation.
But if you want to scale, you have to be asynchronous and you can't
assume that all the 8 bytes will arrive at once.  So you have to have
a little state machine to track the arrival of those bytes.  This is
just needless complication and will be a source of errors.    If the
bytes are framed as WS, then you can simply switch from the HTTP
parser to the WS parser

Also, without any framing, then any 8 bytes sent (eg another HTTP
request) will look like the random bytes.  This is not robust

> I wouldn't block it, but base64 seems better and sufficient.

sure b64 is good also.

cheers

---

From: Adam Barth <[email-masked]>
Date: Wed, 15 Dec 2010 10:11:32 -0800

> I was asked to jot down a few thoughts about the current state of the WebSockets handshake discussion, with an eye to making progress. FWIW:

Thanks.

> I strongly suspect that ALL of the improvement seen in the study can be attributed to (3), because proxies configured to route on the Host header will not be able to forward the message; effectivel…

We did a bunch of tests in the lab before running the large scale
experiment using some proxies we could get our hands on.  The tests
showed that CONNECT was an important factor in preventing the attacks.
 We didn't test all the conditions at scale because adding conditions
at scale is costly, but the at-scale observations confirmed our
in-the-lab expectations,

Adam

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 15 Dec 2010 18:30:10 +0000

FYI, we have submitted a draft that's essentially the handshake that Greg proposed a while back.
We'd like to use it as a basis for further iteration.

http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake

Agree on base64.

Gabriel
________________________________
From: [email-masked] [[email-masked]] on behalf of Greg Wilkins [[email-masked]]
Sent: Wednesday, December 15, 2010 09:03
To: John Tamplin
Cc: [email-masked] HTTP
Subject: Re: [hybi] Shipping WebSockets

sure b64 is good also.

cheers

---

From: Zhong Yu <[email-masked]>
Date: Wed, 15 Dec 2010 14:43:23 -0600

> intermediaries in the path.

The paper did not test the GET+Upgrade handshake, how could it show
that the handshake doesn't work?

> exploit is possible and look for ways to fix the handshake (or change

I am not against conjectures. However it is not academic honesty to
claim that conjectures are confirmed by experiment while they are not.

- Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Wed, 15 Dec 2010 15:07:55 -0600

> at scale is costly, but the at-scale observations confirmed our

As far as I can tell from the paper, and from conversing with your
people on this mailing list, that is not true.

The experiment sent one CONNECT request, followed by a GET request.
According to Collin Jackson, the way to detect whether the
intermediaries parsed into bytes after CONNECT request is to check
whether the GET request came on a different TCP connection. 2 cases
are found. So it is claimed that only in 2 cases(out of 50K cases),
intermediary parsed into bytes after CONNECT, and erroneous extracted
the 2nd request.

That is fallacy. The TCP connection could be reused by intermediary,
so the detection method is moot.

The experiment tells us nothing about the number of interceptors that
parse into bytes after CONNECT request.

see more
http://www.ietf.org/mail-archive/web/hybi/current/msg05074.html

---

From: Adam Barth <[email-masked]>
Date: Wed, 15 Dec 2010 14:25:21 -0800

> people on this mailing list, that is not true.

We didn't report on our in-the-lab tests in the paper, so I'm not sure
what your basis is for claiming that I'm not telling the truth.

I find your statement highly offensive, by the way.

> parse into bytes after CONNECT request.

I'm not sure you understand the experiment.  The experiment is an
end-to-end exploit attempt to poison the cache of the intermediary.
We were able to successfully poison the cache for the Upgrade
handshake but not for the CONNECT handshake.  That does not, of
course, exclude the possibility that there are other attacks against
the CONNECT handshake.  It just shows that this attack works much
better against the Upgrade handshake.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 23:37:32 +0100

> better against the Upgrade handshake.

...but it does not show that the Upgrade handshake can't be secured.

And, as far as I can tell, we even do not know whether the problem would 
have occurred with the message framing in the current draft, right?

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Dec 2010 14:44:47 -0800

> ...but it does not show that the Upgrade handshake can't be secured.

Sure.

> have occurred with the message framing in the current draft, right?
Yes, that's correct. As I think Adam has stated a couple of times now, we
believe that
the handshake should provide as much security as possible without relying on
the framing.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 00:17:50 +0100

> http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake

I find this is a useful step forwards. Good job !

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Dec 2010 11:59:46 +1100

From an HTTP standpoint, this looks good to me, and it nicely demonstrates a point I've been trying to make repeatedly -- that we don't have to fall into the trap of a false choice between the 'old' upgrade proposal and the CONNECT proposal.

I'm very interested to hear the reactions of the CONNECT proponents.

Regards,

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Dec 2010 17:20:52 -0800

> I'm very interested to hear the reactions of the CONNECT proponents.

- I don't think this proposal does anything to address the flaws found by Adam's study.

- In fact I don't think anything about this proposal meaningfully improves security relative to the current draft. Some of the changes may have good non-security motivations I see it as a waste of time to putter around the edges of the handshake until we have security figured out. Security issues currently make the protocol non-viable. I don't see the value in producing more drafts that are not safe to ship in product.

- The summary claims that this handshake doesn't introduce a round trip, but it clearly does, since the hello frames are only exchanged after the handshake completes.

(That's setting aside the obvious point that this internet-draft is not suitable for use as drop-in spec text, both due to being written as an old vs. new comparison and due to insufficient detail.)

For these reasons, I think the proposed draft is not a particularly useful direction.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Wed, 15 Dec 2010 20:21:46 -0500

On Wed, Dec 15, 2010 at 7:59 PM, Mark Nottingham <[email-masked]> wrote:

> From an HTTP standpoint, this looks good to me, and it nicely demonstrates
> a point I've been trying to make repeatedly -- that we don't have to fall
> into the trap of a false choice between the 'old' upgrade proposal and the
> CONNECT proposal.
>

It isn't clear to me that this does anything to stop the potential
vulnerability demonstrated by Adam & Eric's work -- two WebSocket endpoints
can successfully complete the handshake, and a transparent intermediary
might still believe them to be speaking HTTP.  It is conceivable that such
intermediaries would skip intervening garbage to find something that looks
like an HTTP header in attacker-controlled data and be vulnerable to it.

Of the GET+Upgrade proposals that have been made, Dave Cridland's proposal
seems most likely to avoid this by using a fake CONNECT header that those
intermediaries appear to understand to mean they can't interpret remaining
bytes on the connection.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Dec 2010 14:35:00 +1100

> - I don't think this proposal does anything to address the flaws found by Adam's study.

Can you be more specific, Maciej? 

If the hybi-specific handshake is sufficiently unlike an HTTP request/response pair, it should fail when there's an intercepting proxy interposed. 

> - In fact I don't think anything about this proposal meaningfully improves security relative to the current draft. Some of the changes may have good non-security motivations I see it as a waste of…

See above. Perhaps you haven't examined the proposal closely enough.

> - The summary claims that this handshake doesn't introduce a round trip, but it clearly does, since the hello frames are only exchanged after the handshake completes.

I don't see any indication that the client nor server needs to block before sending; only that a certain frame must be sent before any others, in each direction. That shouldn't add a round trip.

> (That's setting aside the obvious point that this internet-draft is not suitable for use as drop-in spec text, both due to being written as an old vs. new comparison and due to insufficient detail.)

As pointed out in the draft, this is a very typical change proposal. If you're going to reject proposals based on their formatting, we are indeed in for the long haul.

Regards,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 07:35:41 +0100

> confused as HTTP(or other protocols) by existing or future programs.

I don't completely agree with you. We're discussing on a list whose
name means "bidirectional HTTP". And "old" draft here from Sal already
mentions WS as one of the bidirectional HTTP protocols :

   http://tools.ietf.org/html/draft-loreto-http-bidirectional-00

And this presentation does so too :

   http://www.ietf.org/proceedings/74/slides/apparea-3.pdf

So the work was really initiated by the wish to get something very
closely tied to HTTP.

> reaching, but also improbable to achieve.

No, at least two mechanisms in HTTP explicitly permit this (CONNECT
for proxies and Upgrade for servers). It's just that we've found some
non-100% compliant implementations that risk to break in a bad way.
Instead of using dirty tricks to make the thing even less compliant
and having more reasons to see it randomly fail, we're trying to make
it compliant and to use tricks to ensure most of the non-compliant ones
will cleanly fail.

Protocol compliance is an important point because it gives an argument
to customers to ask their providers for fixing their products. While you
can sometimes wait several years for a feature upgrade (eg: "please, when
will you support websocket ?") it can be a lot faster when you say "hey,
your crap is subject to CVE-2011-XXXX and my users can exploit it to
corrupt its cache, hurry up to bring a fix".

Another advantage is that instead of having to check multiple docs, the
implementer only has to get back to his beloved HTTP spec and discover
that he did not correctly process the 1xx responses and that he just has
to find a way to get that fixed.

I did it in haproxy, in the past, 1xx would have been considered as 2xx
or 3xx. The fix only took a few hours, tests included. And fixing that
magically brought compatibility with the protocols transported over an
upgrade request.

That's why in my opinion protocol compliance can achieve faster deployment
and adoption than relying on a stack of invalid syntaxes that will make
some valid components break without any incentive for the editors to fix
them.

Regards,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Dec 2010 22:42:29 -0800

> If the hybi-specific handshake is sufficiently unlike an HTTP request/response pair, it should fail when there's an intercepting proxy interposed. 

(1) There's a long distance to go between "should" and "does". Let's see some data.
(2) There's neither evidence or even particular reason to believe that the "hello frame" does this more effectively than the "eight random bytes" in the most recent WG draft.

> See above. Perhaps you haven't examined the proposal closely enough.

Or perhaps you haven't examined both the new proposal and the current draft closely enough. Or the many previous threads on this mailing list where the idea of hello frames and their security benefits (or lack thereof) have been discussed. Or perhaps we should both just argue the merits and not question each other's reading comprehension skills.

I don't see anything in this proposal that provides a meaningful security benefit over the current draft. If anyone believes there is such a benefit, let's hear it. I don't think the hello frames are it, for reasons stated above. In fact, the hello frames have been rejected as providing a security improvement many times, by myself and others. Proposing them yet again does not make them more effective.

> I don't see any indication that the client nor server needs to block before sending; only that a certain frame must be sent before any others, in each direction. That shouldn't add a round trip.

In this design, if the server doesn't wait for the client-side hello frame, then it is not properly validating the client as a WebSocket client. Thus, servers are given the choice between better performance and actually doing correct validation. It seems pretty bad to force this choice on server implementors, especially when there is an alternative that achieves an equally strong level of client validation without an extra round trip, namely payload masking.

> As pointed out in the draft, this is a very typical change proposal. If you're going to reject proposals based on their formatting, we are indeed in for the long haul.

I'm not rejecting it on that basis, I reject it on the basis that it does not improve security, and forces server implementors to choose between performance and security when there are designs that do not do so.

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Dec 2010 18:04:16 +1100

> (1) There's a long distance to go between "should" and "does". Let's see some data.

Agreed.

> (2) There's neither evidence or even particular reason to believe that the "hello frame" does this more effectively than the "eight random bytes" in the most recent WG draft.

So, let's talk about it.

Gabriel and crew are putting forth a proposal, in good faith, to try to move the discussion forward, and dismissing it out of hand doesn't do anyone good at this point.

[...]
> In fact, the hello frames have been rejected as providing a security improvement many times, by myself and others. Proposing them yet again does not make them more effective.

Just as CONNECT has been rejected by many, yet it is still proposed. 

Since this discussion is so long-running, and since new people are starting to get involved, maybe it would be helpful to get some of the common approaches / techniques up on a wiki page, so people can review them (best done as individual techniques rather than whole combined proposals, I'd think).

> In this design, if the server doesn't wait for the client-side hello frame, then it is not properly validating the client as a WebSocket client. Thus, servers are given the choice between better pe…

Thank you, that's moving the discussion forward. Gabriel et al?

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 08:12:00 +0100

On Wed, Dec 15, 2010 at 10:42:29PM -0800, Maciej Stachowiak wrote:
> I don't see anything in this proposal that provides a meaningful security benefit over the current draft. If anyone believes there is such a benefit, let's hear it.

The bytes exchanged between the server and the client after the HTTP
handshake cannot be made to look like an HTTP request nor an HTTP
response, and the client does not talk on the wire until it gets the
server's hello. That should be enough to prevent an attacker controlled
browser from sending fake HTTP requests to an attacker-controlled server
to try to fool intermediaries and corrupt their caches.

I think the trickiest way for an attacker to try to disguise his hello
response would be to try to cover it in the handshake by announcing a
content-length so that the intermediary blindly forwards it until it
gets to some embedded data looking like a response, waiting for a request
to process it. But that does not change the fact that the browser will
still have to send an hello response which does not look like HTTP at
all and which contains invalid chars.

Also it means that we should add that the browser MUST always reject
any body (content-length or transfer encoding) in response to the
handshake (which is not allowed in HTTP anyway but could happen when
dealing with an attacker behind a non-compliant intermediary).

> I don't think the hello frames are it, for reasons stated above. In fact, the hello frames have been rejected as providing a security improvement many times, by myself and others. Proposing them yet again does not make them more effective.

I think that with the bits swapped, the hello frames do not bring any
additional security. However, they're still effective for the client
to know if it can send data over the wire or not, in case it faces a
buggy intermediary that remains stuck on the 1xx response and does not
forward the server's hello. Imagine a chat service for example. It
would not be nice to the user to let him type a lot of text without
knowing whether this text reaches the destination or not, and suddenly
discovering the connection broke on a time-out. With the hello frame,
we have the ability to know whether the connection was really established
or not, despite the possible presence of non-compliant intermediaries.
Remember that was one of Hixie's big concerns from the beginning, and
for a good reason. The 8 random bytes were there for that reason too.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 08:15:13 +0100

> Thank you, that's moving the discussion forward. Gabriel et al?

It depends on what we consider "strong level of client validation" and what
it brings. Unless I'm mistaken, we said in the past that the headers were
enough to ensure the client was a WS agent and not a browser being blindly
directed to a WS URL. What more is needed ?

Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Dec 2010 00:04:39 -0800

>> (2) There's neither evidence or even particular reason to believe that the "hello frame" does this more effectively than the "eight random bytes" in the most recent WG draft.

If anyone has an argument for why hello frames are more effective than the "eight random bytes" mechanism. at protecting intermediaries, I'd be glad to discuss it. Until them I will stand by my current assessment that it gives no security improvement.

> Gabriel and crew are putting forth a proposal, in good faith, to try to move the discussion forward, and dismissing it out of hand doesn't do anyone good at this point.

I reject this way of framing the conversation. Gabriel's proposal is based on a handshake approach that has serious security flaws. This new proposal does not materially do anything to address those flaws relative to the current draft.

We have seen two other proposals that do seem to reasonably address those flaws, namely the CONNECT+invalid host+masking proposal, and the TLS+NPN-only proposal. These are objected to for reasons largely unrelated to security.

I don't think we should focus conversation on a proposal that has no plausible security benefit relative to current baseline.

> Since this discussion is so long-running, and since new people are starting to get involved, maybe it would be helpful to get some of the common approaches / techniques up on a wiki page, so people…

Sounds like a good idea to me. Some proposals have unfortunately not been fleshed out in full detail. We do have internet-drafts incorporating the following:

(1) current WG draft - GET + Upgrade + eight random bytes
(2) Gabriel's draft for GET + Upgrade + hello frames+other random changes
(3) Adam + Eric's draft for CONNECT + invalid host + masking

Other options have been floated, but not spelled out to this level of detail. TLS+NPN; and GET+Upgrade followed by subsequent CONNECT on the stream are notable alternatives that have not been as fleshed out as much as the three above..

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Dec 2010 00:12:39 -0800

> directed to a WS URL. What more is needed ?

Either there is a reason to validate the client HELLO frame, or there isn't. 

(A) If there is no reason to validate it:
   Then why does it include a complicated hash? If its only purpose is to desynchronize intermediaries, a fixed client hello or even a fixed prefix to the first client frame sent would do.

(B) If there is a reason to validate it:
   Then why is it ok to skip the validation?

The design as proposed does not make sense under either alternative.

I would add also that there is no obvious reason for a server hello frame instead of putting the server part of the handshake entirely in response headers, so "symmetry with server hello" is not a very good reason to have the client hello frame either.

Regards,
Maciej

(Personally I think there are good reasons to validate the client, but I believe payload masking serves these purposes more effectively.)

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 09:21:12 +0100

> If anyone has an argument for why hello frames are more effective than the "eight random bytes" mechanism. at protecting intermediaries, I'd be glad to discuss it. Until them I will stand by my cur…

I gave an example in the past. Those "random" bytes can be anything,
including a small HTTP/0.9 request consisting in "GET /\r\n" or
"GET ..\r\n" which is happily accepted by some servers or intermediaries
as a valid HTTP request. Randomness means random things will happen.

Also, the 8 bytes require a round trip between the first intermediary
and the server, and prevent the client from reusing the connection
should anything fail in between (eg: authentication request on an
intermediary).

We discussed having the hello frames reverted in the past but as Greg
suggested, clients will refrain from talking until they see the handshake
for the reason above (connection reuse), thus effectively preventing the
one-round-trip handshake from happening. Greg's proposal (which I was not
fond of at the beginning) solves this issue because the client just has
to send a valid request without risking to lose its connection, then
sends the hello response+data once it gets the handshake+hello from the
server. Most usages will then really be one round-trip.

> I reject this way of framing the conversation. Gabriel's proposal is based on a handshake approach that has serious security flaws.

Care to elaborate on this serious flaw ?

> This new proposal does not materially do anything to address those flaws relative to the current draft.
> 
> We have seen two other proposals that do seem to reasonably address those flaws, namely the CONNECT+invalid host+masking proposal,

and we have explained that invalid host will mean no routing possibility, then
one IP per customer in shared environments. Nice step 15 years backwards,
welcome back to the pre-Host header era !

> and the TLS+NPN-only proposal. These are objected to for reasons largely unrelated to security.

Security is mandatory, but usability too ! You could very well design a
handshake that fails 100% of the time. It will sure be secure, but useful
in what ?

> Other options have been floated, but not spelled out to this level of detail. TLS+NPN; and GET+Upgrade followed by subsequent CONNECT on the stream are notable alternatives that have not been as fl…

This last one merits investigations, maybe it could consist in a cheap hello
protocol based on a CONNECT designed to make a non-compliant intermediary
reliably fail. That's what we're looking for since the beginning.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 09:25:25 +0100

>    Then why does it include a complicated hash? If its only purpose is to desynchronize intermediaries, a fixed client hello or even a fixed prefix to the first client frame sent would do.

If my memory serves me right, the reason for this hello initially was to
ensure that non-compliant intermediaries would reject it as an invalid
request and close the connection. But you have to keep in mind that the
hello frame was supposed to be a minor change from the initial 8-bytes
nonce. It certainly could be improved (or removed) if the points you
mention indicate some parts are not needed anymore.

> I would add also that there is no obvious reason for a server hello frame instead of putting the server part of the handshake entirely in response headers, so "symmetry with server hello" is not a…

The only reason for a framed hello is to ensure that the channel is
really open on top of intermediaries, nothing else. It is possible
that we don't need to check that from the server side at all. Having
the server send its hello is enough for the client to know the channel
is opened in the opposite direction, and the new framing with bits
swapped is enough to ensure the client will not accidentely send a
frame that looks like HTTP.

Regards,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 09:44:39 +0100

Hi there,

What is clear from the discussion is that all the handshakes that have 
been formally proposed will have some impact on the intermediaries...
or at least that
all the handshakes that have been formally proposed present several issues
(e.g. security flaws for Upgrade; not in keeping with the semantic for 
Connect; etc);
arguing against the handshake one thinks doesn't work, without trying to 
address the concerns/issues that have been raised by the other on
the one we likes does not help to make progress.

The Gabriel's (or Greg's) proposal has  the merit to move the discussion 
in a positive way.
At least it is a tentative to iterate on an proposed solution (actually 
on the one currently in the 03 version)
and discuss it in a positive way to see how to improve it... as the 
authors and other people in the ml think that it is possible to improve it.

The Adam paper has a lot of merit on highlighting problem with the 
handshake currently in the 03 version of the WebSocket protocol,
and also in showing that the Connect handshake seems to perform well (or 
at least much better).
However, as chair, I would like to see an iteration on the CONNECT 
proposal (if the authors want still push for that solution)
  that address or a tentative to address the concerns/issues raised by 
people in the ml on the usage of CONNECT as well as on the other
aspect of the proposal.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 09:50:26 +0100

Hi there,

as chair I want encourage people to change the subject of the thread and 
keep it consistently
with what the thread discussion is about...
that will help people to follow the discussion as it happens and also to 
find it on the ml archive.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Dec 2010 10:03:01 +0100

> handshake currently in the 03 version of the WebSocket protocol,

s/03/00/, right?

Best regards, Julian

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 16 Dec 2010 01:07:58 -0800

>> handshake currently in the 03 version of the WebSocket protocol,

handshake is basically the same in 00 and 03...

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 16 Dec 2010 01:09:42 -0800

On Thu, Dec 16, 2010 at 12:44 AM, Salvatore Loreto <
[email-masked]> wrote:

> Hi there,
>
>
> What is clear from the discussion is that all the handshakes that have been
> formally proposed will have some impact on the intermediaries...
> or at least that
> The Gabriel's (or Greg's) proposal has  the merit to move the discussion in
> a positive way.
> At least it is a tentative to iterate on an proposed solution (actually on
> the one currently in the 03 version)
> and discuss it in a positive way to see how to improve it... as the authors
> and other people in the ml think that it is possible to improve it.
>
>
> and also in showing that the Connect handshake seems to perform well (or at
> least much better).
> However, as chair, I would like to see an iteration on the CONNECT proposal
> (if the authors want still push for that solution)
I thought the one I emailed out, and subsequent discussion about dropping
e.g. websocket.invalid, addressed most of the concerns. The remaining
concern seemed to be about the semantics of CONNECT, and I am unclear what
sort of iteration would address that.

---

From: John Tamplin <[email-masked]>
Date: Thu, 16 Dec 2010 04:16:56 -0500

> sort of iteration would address that.

I think Dave's proposal addresses that by making sure that a CONNECT appears
on the wire only after verifying the endpoint is WebSocket-aware, so it
isn't actually an HTTP request and exists only to make transparent
intermediaries that don't understand GET+Upgrade treat the rest of the
session as opaque.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 10:18:43 +0100

On 12/16/10 10:09 AM, Ian Fette (イアンフェッティ) wrote:
> On Thu, Dec 16, 2010 at 12:44 AM, Salvatore Loreto 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi there,
>
>
>     What is clear from the discussion is that all the handshakes that
>     have been formally proposed will have some impact on the
>     intermediaries...
>     or at least that
>     (e.g. security flaws for Upgrade; not in keeping with the semantic
>     for Connect; etc);
>     arguing against the handshake one thinks doesn't work, without
>     trying to address the concerns/issues that have been raised by the
>     other on
>     The Gabriel's (or Greg's) proposal has  the merit to move the
>     discussion in a positive way.
>     At least it is a tentative to iterate on an proposed solution
>     (actually on the one currently in the 03 version)
>     and discuss it in a positive way to see how to improve it... as
>     the authors and other people in the ml think that it is possible
>     to improve it.
>
>
>     and also in showing that the Connect handshake seems to perform
>     well (or at least much better).
>      that address or a tentative to address the concerns/issues raised
>     by people in the ml on the usage of CONNECT as well as on the other
>     aspect of the proposal.
>
>
> I thought the one I emailed out, and subsequent discussion about 
> dropping e.g. websocket.invalid, addressed most of the concerns. The 
> remaining concern seemed to be about the semantics of CONNECT, and I 
> am unclear what sort of iteration would address that.

you are right!
what I meant is that is haven't seen any discussion about the semantic 
issue people have raised
neither an iteration that try to use CONNECT in a way conform to its 
semantic

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Adam Barth <[email-masked]>
Date: Thu, 16 Dec 2010 01:27:50 -0800

On Thu, Dec 16, 2010 at 1:18 AM, Salvatore Loreto
<[email-masked]> wrote:
> <[email-masked]> wrote:
>>
>> Hi there,
>>
>>
> what I meant is that is haven't seen any discussion about the semantic issue
> people have raised

The draft that Ian sent to this list uses CONNECT in a way that
conforms to its semantics.

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 16 Dec 2010 10:50:12 +0100

>http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake

This seems broken to me if you make three assumptions: implementations
don't stop normal HTTP processing if they see a 101 (that's the working
assumption that makes us discuss handshakes at all); it's fairly common
for servers to send response bodies when they are not supposed to, e.g.
in response to HEAD requests, so implementations treat unexpected bodies
as part of the response to the previous request; implementations do only
very limited input validation, for instance, when looking for a method,
they just skip to the next white space octet.

With these assumptions it would seem the server->client hello would be
treated as response body and the client->server hello as request method.
Since what follows the unknown request method is essentially controlled
by the attacker, that amounts to a normal HTTP request. I am sure each
of these flaws can be found in deployed software; their combination plus
additional behavior that makes them exploitable (you also need, say,
persistent connections) is probably rare, but unless I am misreading the
document, this seems insufficient if you care a lot about this problem.
-- 
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: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 10:55:40 +0100

> conforms to its semantics.
well, at least from the mail discussion seems that there are people that
do not think so.

It would be good to discuss it ... and clarify (if possible) the
concerns people have.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 11:06:05 +0100

> It would be good to discuss it ... and clarify (if possible) the
just as an example... the point raised by Roy:
http://www.ietf.org/mail-archive/web/hybi/current/msg04864.html

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 11:16:16 +0100

> document, this seems insufficient if you care a lot about this problem.

If the server's data is treated as a response body, this is fine, because
it will be treated as the handshake request's response, it cannot be sent
as a response to a second request.

The processings we can see on a 101 response are :
  - intermediary considers 1xx as error and stops => OK

  - intermediary does not know about 1xx and forwards it as it would for
    a 2xx or 3xx => since we have no content-length, the end of the response
    is indicated by closing the connection after the "body"

  - intermediary only knows that 1xx has no body but forwards it as a
    single response and believes that what follows is the response to
    a second request => the client hello must be accepted as a valid
    HTTP request for the server hello to be parsed, then accepted in
    turn as a valid HTTP response. None of them look like HTTP, and
    that's the point.

  - intermediary knows that 1xx is an intermediate message without body
    and waits for a second one right after it => it parses the server
    hello expecting to find an HTTP response here, which it does not
    look like at all.

  - intermediary knows about 101 and establishes the bidirectional tunnel
    between the two sides and we're OK.

I don't see a way to abuse any non-compliant intermediary here.

Regards,
Willy

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 16 Dec 2010 02:20:31 -0800

RFC2817:

" An origin server which receives a CONNECT request for itself MAY

   respond with a 2xx status code to indicate that a connection is
   established."

2010/12/16 Salvatore Loreto <[email-masked]>

> dropping
> issue

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 11:26:31 +0100

>    respond with a 2xx status code to indicate that a connection is

Indeed. However there is no way for an intercepting proxy to distinguish
this from a proxy request (eg: try it on a squid configured as a transparent
proxy and it will fail).

Regards,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Dec 2010 02:42:15 -0800

Under what circumstances would you configure an intercepting proxy to
process CONNECT?
The whole point of CONNECT is that you know you have a proxy in the way.
That's why
you're doing CONNECT. If you're an intercepting proxy and you see CONNECT it
is
almost certainly directed at someone else and so stripping it is going to
break all sorts
of stuff.

-Ekr

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Dec 2010 11:49:09 +0100

Hi Eric,

from some test I have done
there are transparent proxies especially in Telecom networks
that treats CONNECT in the same way as the non-transparent proxies.
They establish a TCP connection with the target node, but they never 
forwards
the "CONNECT ..." message itself.

In design an handshake based on CONNECT that is something to take in 
consideration.

cheers
/Sal

On 12/16/10 11:42 AM, Eric Rescorla wrote:
> The whole point of CONNECT is that you know you have a proxy in the 
> way. That's why
> you're doing CONNECT. If you're an intercepting proxy and you see 
> CONNECT it is
> almost certainly directed at someone else and so stripping it is going 
> to break all sorts
> of stuff.
>
> -Ekr
>
>
> On Thu, Dec 16, 2010 at 2:26 AM, Willy Tarreau <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 
Salvatore Loreto
www.sloreto.com

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 16 Dec 2010 12:24:24 +0100

>as a response to a second request.

If the server->client hello is conisdered part of the response body to
the upgrade request, it would seem the server->client hello will make it
to the client. Once the client sees the server->client hello, it can
send the client->server hello plus bytes chosen by the attacker, with
the intermediary considering client->server hello plus attacker bytes a
HTTP request. That is precisely what the handshake is supposed to avoid.

Is there something I am missing, or is the idea to rely on the inter-
mediary to not act on this spoofed request (say, because it is still
reading the response to the last request)?
-- 
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: Greg Wilkins <[email-masked]>
Date: Thu, 16 Dec 2010 13:45:25 +0100

> - I don't think this proposal does anything to address the flaws found by Adam's study.

The proposal is not specifically aimed at just fixing the issues found
in Adams study.

It was primarily motivated by the long standing issue that the 8
random bytes are not HTTP compliant and we have an open issue about
how it is breaking good intermediaries that would otherwise respect a
proper Upgrade -> 101 conversation.

The changes to framing are somewhat aimed at the security issue found
by Adam, but more study is needed to determine if they are effective
and/or efficient.     However, as the -76 handshake is also not
secure, I don't think that security concerns should stop us making
otherwise well justified improvements to the handshake.   Nobody is
saying this is the end of the story, just a logical next step.

> - The summary claims that this handshake doesn't introduce a round trip, but it clearly does, since the hello frames
> are only exchanged after the handshake completes.

Please re-read the proposal.  You are not understanding it.   The only
requirement is that the first frame in either direction is a Hello
frame.  The server starts first, after the 101 is sent.  The client
has to wait for the 101 anyway.

[snip new email]
> If anyone has an argument for why hello frames are more effective than the "eight random bytes" mechanism. at
> protecting intermediaries, I'd be glad to discuss it. Until them I will stand by my current assessment that it gives no
> security improvement.

The Hello frames are an improvement over the 8 bytes for several reasons:

 1) The server sends them first, so it fixes the problem with good
intermediaries waiting for a response before sending the 8 bytes.
This is a demonstrated problem with the -76 handshake and is not not
HTTP compliant.

 2) The 8 random bytes are random. Thus a following HTTP request can
be interpreted as those bytes and cannot be validated.  A Hello frame
can be validated and a HTTP request or response cannot be seen as a
Hello frame.

3) Framing the bytes as WS avoids the need to have 3 different
framings over the 1 connection (HTTP, byte count, & WS). This
simplifies implementations and will result in less bugs.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Dec 2010 13:52:39 +0100

All,

i would like to stress that Gabriel and my proposal is not meant to be
exclusive of any consideration using alternative methods like CONNECT
or WEBSOCKET.

It is not intended to be the end of the line in consideration, just a
logical next step to fix some of the know and demonstrated problems
with the existing handshake, as well as some potential (but untested)
strengthening in regards to the issues that Adam has investigated.

Adopting this proposal would not mean that we have decided to use
GET+Upgrade.  It would mean only that we have improved our current
GET+Upgrade draft somewhat and we can continue to review if it is
sufficient or if a CONNECT based handshake is needed.    I think Hello
frames are a good idea even with CONNECT because they immediately test
the connection even if no messages are available to send/receive.
Note that I don't really care what the Hello frames carry and I'd be
happy for the nonces to move to headers.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Dec 2010 13:56:51 +0100

>    respond with a 2xx status code to indicate that a connection is

Note that this is itself somewhat of a weakness of connect, because
there are dumb servers that don't check the method and that might send
a 2xx response without realizing that they are accepting a CONNECT.
I think the other headers in the handshake do protect against this,
but the positive 101 response to an upgrade is a much more definitive
acceptance of a websocket handshake.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Dec 2010 14:23:32 +0100

On 16 December 2010 09:04, Maciej Stachowiak <[email-masked]> wrote:

> I don't think we should focus conversation on a proposal that has no plausible
> security benefit relative to current baseline.

The proposals are not only for security reasons.

The current handshake is not HTTP client and has a demonstrated issue
with the 8 random bytes not being passed by valid intermediaries that
would correctly handle a compliant Upgrade+101.

There are also some elements of the proposal that may strengthen the
handshake against the vulnerability that Adam identified, but they
have yet to be tested (nor has a real -76 handshake for that matter).

I accept that it may not fully resolve that security issues and we do
need to consider other proposals based on CONNECT and/or masking, but
that is not a valid reason to prevent the incremental improvement of
the current GET+Upgrade to fix known issues unrelated to security.

There are no perfect solutions and preventing all progress until
somebody finds a perfect solution is just not productive.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 17:14:25 +0100

> Under what circumstances would you configure an intercepting proxy to

There is no obvious reason to make it support the method (or maybe some
obscure situations where the proxy is shared between intercepting mode
and non-intercepting mode, but that's for people looking for issues).

What I've observed is simply a squid set up to support interception and
which did not have CONNECT disabled. It's already in production and supports
CONNECT despite being used to intercept data. Such setups might be more
common than admins think because a normal client will not send a CONNECT
there, so until now having it enabled will not break anything.

> almost certainly directed at someone else and so stripping it is going to

100% agreed, and if I were administering such components, I would probably
take care of removing its support, or better try to forward the CONNECT
unmolested as we'd like it to work as proposed in your and Adam's handshake.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 17:16:22 +0100

> the "CONNECT ..." message itself.

That's precisely in the same context I observed it, but I'm not authorized
to bring more information about this usage.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Dec 2010 17:20:12 +0100

On Thu, Dec 16, 2010 at 12:24:24PM +0100, Bjoern Hoehrmann wrote:
> HTTP request.

That's why it's important that the first message from the client to the
server cannot look like HTTP.

> That is precisely what the handshake is supposed to avoid.

The handshake already avoids that by design on a protocol standpoint,
except that there are a bunch of buggy implementations that can make
that asumption fail. That's why we're trying to have most of them fail
in a more-or-less controlled way when subject to a valid handshake.

> reading the response to the last request)?

No, you're not missing anything. Please check Greg's recent post for a
more detailed analysis.

thanks,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Dec 2010 18:11:29 +0100

>> Under what circumstances would you configure an intercepting proxy to

With Jetty, our Proxy handler can be used both as a real proxy and as
a transparent proxy. Connect support used to be able to be enabled for
either and I'm sure it has often been wrongly deployed with
transparent connect support.   Note that we now have moved Connect to
a completely separate handler, but there are still deployments of
jetty 3 out there, so it's impossible to take that mistake back.

regards

---

From: Joe Mason <[email-masked]>
Date: Thu, 16 Dec 2010 13:11:14 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Greg Wilkins
> Sent: Thursday, December 16, 2010 7:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [hybi] semantic conformance in CONNECT handshake proposal
> (was Re: Handshake proposals, how to move forward)
> 

The more we get into the details of CONNECT, the more I like Dave Cridland's Upgrade followed by CONNECT proposal.  The initial Upgrade gets a 101 response, which as you say is more definitive, and the following connect seems like it will do all the things we want from a plain CONNECT without needing to worry about routing.

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: Joe Mason <[email-masked]>
Date: Thu, 16 Dec 2010 13:11:15 -0500

> Willy Tarreau
> Sent: Thursday, December 16, 2010 2:12 AM
> To: Maciej Stachowiak
> Cc: [email-masked] HTTP

I'm also convinced by the ease of implementation argument that since we must write a frame parser anyway, there is no reason not to parse the initial data exchange with it, rather than having to write another state machine for the unframed data.  So I support converting the unframed bytes in the current handshake to frames, at least as a stop-gap. 

Joe

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Dec 2010 13:42:03 -0800

> Other options have been floated, but not spelled out to this level of detail. TLS+NPN; and GET+Upgrade followed by subsequent CONNECT on the stream are notable alternatives that have not been as fl…

So we seem to have a WG wiki, but I am not sure how to get an account that would allow me to edit it.
http://tools.ietf.org/wg/hybi/trac/wiki

Does anyone know how to get edit rights on this wiki?

Regards,
Maciej

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 16 Dec 2010 16:43:28 -0500

> Does anyone know how to get edit rights on this wiki?

For tools questions, I would start with Henrik Levkowetz <[email-masked]> (cc:ed here).

Regards
Marshall

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Dec 2010 08:44:29 +1100

http://trac.tools.ietf.org/tools/loginmgr/newlogin

Cheers,

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Dec 2010 16:19:30 -0800

Here is a bare bones version of the Wiki page:

http://trac.tools.ietf.org/wg/hybi/trac/wiki/HandshakeProposals

I listed some of the criteria (with little elaboration), and the five proposals that have been written up in detail, with a short summary. I have not added any discussions of advantages or disadvantages. Also it made me sad that there was no detailed proposal for a TLS+NPN handshake, to a similar level of detail to the five listed.

Others should feel free to enhance this page.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Thu, 16 Dec 2010 19:22:56 -0500

On Thu, Dec 16, 2010 at 7:19 PM, Maciej Stachowiak <[email-masked]> wrote:

> Also it made me sad that there was no detailed proposal for a TLS+NPN
> handshake, to a similar level of detail to the five listed.
>

I believe the schedule uncertainty meant it wasn't seriously considered --
however, at the rate we are currently progressing that likely won't be a
problem :).

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 17 Dec 2010 09:09:41 +0100

Maciej,

the problem with this wiki page is that it does not decompose the
issues and presents them as a fixed choice between mutually exclusive
alternatives.

The proposal that Gabriel and I have made is about fixing the current
known HTTP issues and is not necessarily exclusive of other handshake
proposal.    Hello packets could work equally as well with CONNECT,
and/or masking and/or aspects of other proposals.

I'm not sure it is constructive to put the proposals about Hello
frames in direct competition with the other proposals.   Supporting
Hello frames does not mean you cannot support aspects of the other
proposals.

regards

---

From: James Graham <[email-masked]>
Date: Fri, 17 Dec 2010 10:22:45 +0100

> http://trac.tools.ietf.org/wg/hybi/trac/wiki/HandshakeProposals

Great! Thanks for doing this Maciej.

> I listed some of the criteria (with little elaboration), and the five
> proposals that have been written up in detail, with a short summary.
> I have not added any discussions of advantages or disadvantages.

I would find it helpful if we could move some synopsis of the reasons 
for each design having the features it has, and any points — positive or 
negative — to consider when evaluating those features, to the wiki. The 
volume of traffic on the mailing list has been to much to follow in 
detail, and I get the impression that there is a good deal of 
repetition. This should also address Greg's objection because it should 
become easy to see if some re-composition of features from different 
proposals would be a good basis for a new proposal.

>Also
> it made me sad that there was no detailed proposal for a TLS+NPN

Indeed. Who do we need to bribe to write up a proposal for this approach? ;)

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Dec 2010 03:04:36 -0800

> Hello frames does not mean you cannot support aspects of the other

I listed the proposals that were written up in sufficient detail to evaluate, as a starting point. I agree that there is lots more information that we could collect, such as a list of potentially separate changes. You're welcome to add any info you like to the page. I plan to add more information myself to it as time permits.

I do agree that in theory it would be good to list orthogonal decision points separately. But the interactions can be complex. For example, payload masking and hello frames partially serve the same purpose. Alternately, the decisions of whether to have client hello frames and server hello frames could be independent. Because it takes some thought and study to decide the right level of breakdown, I started by listing the combinations of choices that have been written up in full detail.

As I mentioned, you are welcome to add more, or to correct any information on the page that may be inaccurate.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Dec 2010 03:06:53 -0800

On Dec 17, 2010, at 1:22 AM, James Graham wrote:

> I would find it helpful if we could move some synopsis of the reasons for each design having the features it has, and any points — positive or negative — to consider when evaluating those features, to the wiki. The volume of traffic on the mailing list has been to much to follow in detail, and I get the impression that there is a good deal of repetition. This should also address Greg's objection because it should become easy to see if some re-composition of features from different proposals would be a good basis for a new proposal.

I plan to add more detail to this page, but I may not be able to do so until January, as I will imminently be on holiday. Others are welcome to add to it themselves, of course.

Regards,
Maciej

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 17 Dec 2010 14:00:06 +0100

> http://trac.tools.ietf.org/wg/hybi/trac/wiki/HandshakeProposals
Hi Maciej,

thanks a lot for the initiative and the time you have spent to organize 
the page.
I do appreciate it.

I have now make it accessible also from the HyBi wiki main page
http://trac.tools.ietf.org/wg/hybi/trac/wiki

I think that it would be good also collect links to paper describing the
cross protocols attacks as well as the paper written by Adam
that analyzes the issues with the current proposal!
I'll ask Adam permission to add a point to that.

> I listed some of the criteria (with little elaboration), and the five proposals that have been written up in detail, with a short summary. I have not added any discussions of advantages or disadvan…
from a chair prospective,
if nobody bother to write down a detailed proposal on TLS+NPN that just 
means that nobody wants it
so strongly to spend time to push for it.
Until we have a formal proposal we cannot say anything else that 
TLS+NPN  *MAYBE* is the only/right solution.
I can only easily guess that once we have the first proposal we will 
have to iterate it to address all the
concerns/issues that people will raise.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Dec 2010 11:17:48 -0800

On Fri, Dec 17, 2010 at 5:00 AM, Salvatore Loreto <
[email-masked]> wrote:

>> proposals that have been written up in detail, with a short summary. I have
>> not added any discussions of advantages or disadvantages. Also it made me
>> sad that there was no detailed proposal for a TLS+NPN handshake, to a
>> similar level of detail to the five listed.
>>

That's not the situation at all. Rather, there have been a number of NPN
proposals that were pushed back
on so hard by some WG members that I think most people who would prefer TLS
all the time felt it
wasn't worth it producing a formal proposal. If that option is still open, I
or Adam can produce one,
but I'm not going to waste my time if it's just going to be dismissed out of
hand.

-Ekr

> Until we have a formal proposal we cannot say anything else that TLS+NPN
>  *MAYBE* is the only/right solution.
> I can only easily guess that once we have the first proposal we will have
> to iterate it to address all the

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 17 Dec 2010 14:48:46 -0700

> but I'm not going to waste my time if it's just going to be dismissed out of

After your paper it seems a lot more reasonable. I would like to see
such a proposal.

jack.

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 18 Dec 2010 11:35:08 +0100

On 12/17/10 8:17 PM, Eric Rescorla wrote:
>
>
> On Fri, Dec 17, 2010 at 5:00 AM, Salvatore Loreto 
>         I listed some of the criteria (with little elaboration), and
>         the five proposals that have been written up in detail, with a
>         short summary. I have not added any discussions of advantages
>         or disadvantages. Also it made me sad that there was no
>         detailed proposal for a TLS+NPN handshake, to a similar level
>         of detail to the five listed.
>
>     if nobody bother to write down a detailed proposal on TLS+NPN that
>     just means that nobody wants it
> That's not the situation at all. Rather, there have been a number of 
> NPN proposals that were pushed back
> on so hard by some WG members that I think most people who would 
> prefer TLS all the time felt it
> wasn't worth it producing a formal proposal. If that option is still 
> open, I or Adam can produce one,
> but I'm not going to waste my time if it's just going to be dismissed 
> out of hand.
Hi Eric,

my feeling, from the ml, is that a lot of people are starting to 
consider the possibility to use TLS... so I don't think it is something
that will be dismissed out of hand, of course as always in IETF there is 
no guaranty to reach a rough consensus
on a proposal (e.g. TLS in this case), but if nobody try we will never know.

Of course a full complete TLS proposal to take or leave it will face the 
same amount of parallel discussions
on different issues ...
in order to have a more productive discussion, and also not let you wast 
a lot of time producing a full proposal,
  I would suggest to start discuss how a TLS handshake should work step 
by step
(possibly with a separate thread for each separate issue)

cheers
/Sal

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 20 Dec 2010 14:13:35 +0100

Hi Maciej,

...
>> Does anyone know how to get edit rights on this wiki?

All you should need is a login, which you set up here:

  http://tools.ietf.org/newlogin

Best,

	Henrik

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 Dec 2010 13:28:35 +0000

On Thu Dec 16 08:04:39 2010, Maciej Stachowiak wrote:

> Sounds like a good idea to me. Some proposals have unfortunately  
> not been fleshed out in full detail. We do have internet-drafts  
> incorporating the following:
> 
> Other options have been floated, but not spelled out to this level  
> of detail. TLS+NPN; and GET+Upgrade followed by subsequent CONNECT  
> on the stream are notable alternatives that have not been as  
> fleshed out as much as the three above..

I've put out a basic draft covering the GET+Upgrade+CONNECT. What's  
missing, in your view, that 2/3 currently have in terms of details  
needed to evaluate it properly?

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: Dave Cridland <[email-masked]>
Date: Mon, 20 Dec 2010 13:28:40 +0000

On Thu Dec 16 18:11:14 2010, Joe Mason wrote:
> The more we get into the details of CONNECT, the more I like Dave  
> Cridland's Upgrade followed by CONNECT proposal.  The initial  
> Upgrade gets a 101 response, which as you say is more definitive,  
> and the following connect seems like it will do all the things we  
> want from a plain CONNECT without needing to worry about routing.

Right, that's the point. I think incorporating Greg's proposals on  
bit-flipping should decrease the possibility of websocket data flows  
being interpreted, too.

Dave.

---

From: SM <[email-masked]>
Date: Mon, 20 Dec 2010 12:01:47 -0800

At 16:08 14-12-10, Mark Nottingham wrote:
>* Ports and Security
>
>It's clear that making WebSockets safe for transit over port 80 is 
>non-trivial. The arguments for allowing it over port 80 are mostly 
>centred on its well-known ability to transit firewalls and other 
>forms of port blocking.
>
>First, it's important to acknowledge the paradox of this approach. 
>We're saying that we want to maximise our chances of success by 
>reusing a port where we know there is a large amount of existing, 
>non-compatible traffic, and that often that traffic is intercepted 
>in ways that are not compatible with the new application.

Some people view TCP port 80 and 443 as the only ports required for 
Internet access.  The discussions have focused on walking the tight 
rope; i.e. how to get Websocket through these two ports in a HTTP 
complaint way.  There are protocols designed outside that IETF that 
do that already.  The difference is that these protocols do not have 
to go through IETF-wide review.

>Reusing port 80 as the default port for WebSockets, even though the 
>nature of the traffic is significantly different, is extremely 
>hostile to firewall administrators. Some will selectively block 
>WebSockets traffic based upon a signature, and will eventually 
>deploy software that intercepts and inspects WebSockets traffic, 
>just as is done for HTTP today.

Yes.  It's better to let the user-base decide what traffic it wants 
to allow through.  Otherwise, it becomes a cat and mouse game where 
the user-base implements measures to block such traffic.  The 
downside is that it also makes it more difficult to allow such 
traffic through unmolested.

>Given that the IETF represents not only the browser vendors and 
>server-side application developers, but also the network operators 
>and vendors for network hardware and software, I question whether 
>it's prudent to effectively lie to ourselves; to run non-HTTP 
>traffic over the HTTP port, in the name of expedience, when in the 
>long term, the result will be the same -- sites that want to block 
>WebSockets traffic will, and sites that want to offer the improved 
>services that WebSockets promises will allow it.

The short term gain is more enticing than the pain of deployment.

>1) Define a default high port for WS, disallow it on port 80, allow 
>it on 443. Measures for counteracting interception proxies should be 
>unnecessary (and the handshake can look however we like), it's 
>possible to use as log as 443 is available, and we can get on with our lives.

You could define a port Websocket and ignore the question of port 
80.  If you are not using port 80, it's difficult to argue for 
allowing it on port 443 unless you are specifically designing a 
protocol to get around contemporary firewalls.

Regards,
-sm

---

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

On Dec 20, 2010, at 5:28 AM, Dave Cridland wrote:

> I've put out a basic draft covering the GET+Upgrade+CONNECT. What's missing, in your view, that 2/3 currently have in terms of details needed to evaluate it properly?

I initially failed to notice it, but it was pointed out to me after I sent the message you quoted, and it is listed on the wiki page.

Regards,
Maciej

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 09:13:41 +0000

On Mon Dec 20 21:06:44 2010, Maciej Stachowiak wrote:
> I initially failed to notice it, but it was pointed out to me after  
> I sent the message you quoted, and it is listed on the wiki page.

I'm not surprised - the volume on this mailing list is sufficiently  
high that I have no doubt I've missed feedback on my proposal.

Dave.