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

From: "Simon Pieters" <[email-masked]>
Date: Tue, 30 Nov 2010 16:56:34 +0100

Hi,

At Opera we do not plan to implement the new framing until the spec uses a  
CONNECT-based handshake. We support Adam and Eric's handshake proposal.

-- 
Simon Pieters
Opera Software

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2010 17:24:56 +0100

On 30.11.2010 16:56, Simon Pieters wrote:
> Hi,
>
> At Opera we do not plan to implement the new framing until the spec uses
> a CONNECT-based handshake. We support Adam and Eric's handshake proposal.

What does the framing have to do with the switch from HTTP?

Best regards, Julian

---

From: James Graham <[email-masked]>
Date: Tue, 30 Nov 2010 17:44:47 +0100

> What does the framing have to do with the switch from HTTP?

The point is that we are not likely to make an interim implementation of 
the latest framing but with the -00 handshake. It is not clear what 
others are planning to do here although at least the Chrome team were 
talking about an in-progress implementation of the new framing that 
predated the handshake discussion.

It also seems clear from Adam's work that there are considerable 
problems with the existing Upgrade-based handshake. Therefore switching 
to the -abarth design, which is known to avoid many of these problems, 
seems like the correct way forward.

As usual, I will point out that websockets -00 is currently deployed by 
multiple UAs. The longer that it takes to come to agreement about a 
final version that we can all implement, the smaller the chance of that 
final version supplanting -00.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 30 Nov 2010 08:46:23 -0800

On Tue, Nov 30, 2010 at 8:44 AM, James Graham <[email-masked]> wrote:

> the latest framing but with the -00 handshake. It is not clear what others
> are planning to do here although at least the Chrome team were talking about
> an in-progress implementation of the new framing that predated the handshake
> discussion.
>
> It also seems clear from Adam's work that there are considerable problems
> with the existing Upgrade-based handshake. Therefore switching to the
> -abarth design, which is known to avoid many of these problems, seems like
> the correct way forward.
>
> multiple UAs. The longer that it takes to come to agreement about a final
> version that we can all implement, the smaller the chance of that final
> version supplanting -00.
>
>
I would be happy to ship abarth's proposal.

-Ian

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Nov 2010 17:56:07 +0100

On 30.11.2010 17:44, James Graham wrote:
> ...

There are several updates since -00 which appear to be better than -00. 
Sticking with -00 because the current version is not perfect is the 
wrong thing to do here.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 30 Nov 2010 18:09:44 +0100

> Sticking with -00 because the current version is not perfect is the  

Sorry, but we are not interested in chasing specification updates.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 30 Nov 2010 18:12:28 +0100

> I would be happy to ship abarth's proposal.

That would be great!

---

From: Joe Mason <[email-masked]>
Date: Tue, 30 Nov 2010 13:08:44 -0500

> -----Original Message-----

Our position at RIM is similar.  We basically have 3 incompatible versions of websockets under discussion here: -00, -03, and the hypothetical "-03+new handshake".  We haven't shipped a WebSockets enabled browser yet, and we're hoping the new handshake can be locked down soon so that we can ship "-03+new handshake" as our first version.  But if it drags on too much longer we'll be forced to ship -00 just so that our users can have some version of websockets.  We have no plans to ship -03 when it's known that it will be obsolete as soon as the new handshake is ready, because that would multiply the number of incompatible versions in the wild.

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: John Tamplin <[email-masked]>
Date: Tue, 30 Nov 2010 13:12:41 -0500

On Tue, Nov 30, 2010 at 1:08 PM, Joe Mason <[email-masked]> wrote:

> Our position at RIM is similar.  We basically have 3 incompatible versions
> of websockets under discussion here: -00, -03, and the hypothetical "-03+new
> handshake".  We haven't shipped a WebSockets enabled browser yet, and we're
> hoping the new handshake can be locked down soon so that we can ship
> "-03+new handshake" as our first version.  But if it drags on too much
> longer we'll be forced to ship -00 just so that our users can have some
> version of websockets.  We have no plans to ship -03 when it's known that it
> will be obsolete as soon as the new handshake is ready, because that would
> multiply the number of incompatible versions in the wild.
>

Since v00 is already known to be obsolete, I don't see how that is better.

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 30 Nov 2010 10:24:30 -0800

On Nov 30, 2010, at 7:56 AM, Simon Pieters wrote:

> Hi,
> 
> At Opera we do not plan to implement the new framing until the spec uses a CONNECT-based handshake. We support Adam and Eric's handshake proposal.

Speaking personally, I am also in favor of Adam and Eric's proposal for a CONNECT-based handshake, as well as the associated payload masking. I expect many of my Apple colleagues would agree.

We would be hesitant to ship protocol updates that do not fix the handshake. Given the security issues identified by the paper from Adam and company, we would even consider disabling WebSocket entirely in future releases until there is a more robust handshake.

(However, I make no specific promises about future Safari releases.)

Regards,
Maciej

---

From: Joe Mason <[email-masked]>
Date: Tue, 30 Nov 2010 13:25:20 -0500

> From: John Tamplin [mailto:[email-masked]] 
> Sent: Tuesday, November 30, 2010 1:13 PM
> To: Joe Mason
> Cc: James Graham; [email-masked]
>

As I said, we’re hoping not to have to ship it.  But if the discussion drags on without producing another candidate for much longer, -00 will remain the de facto standard, officially obsolete or not.  Unless a large number of browser vendors all decide to ship -03 with the old handshake (in which case I assume we will go along in order to remain compatible).  But this would be basically giving up on a new handshake, since nobody is going to want to switch to a third incompatible version in a row.

What I'm saying is: let's get a decision, so nobody has to make these hard choices.

Joe

---

From: Joe Mason <[email-masked]>
Date: Tue, 30 Nov 2010 13:31:20 -0500

> As I said, we’re hoping not to have to ship it.  But if the discussion
> drags on without producing another candidate for much longer, -00 will
> remain the de facto standard, officially obsolete or not.

I should also mention, after seeing Adam's paper, we may decide not to throw the switch on -00 after all even if -03+new handshake isn't ready.  But our plan in that case will still be -03+new handshake or nothing.

Joe

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 30 Nov 2010 10:39:13 -0800

So, can we make a decision? CCing Joe and Sal, I would like to see a call
for consensus.

On Tue, Nov 30, 2010 at 10:31 AM, Joe Mason <[email-masked]> wrote:

> I should also mention, after seeing Adam's paper, we may decide not to
> throw the switch on -00 after all even if -03+new handshake isn't ready.
>  But our plan in that case will still be -03+new handshake or nothing.
>
> 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: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 30 Nov 2010 10:40:22 -0800

(And for the record, I am happy to put out a revision based on abarth's
proposal. I am also happy to try to re-write it in a format that people find
easier to grok, as opposed to the current handshake's "read 1 byte, call it
X" style. I will probably mess something up in the first attempt at doing
that, and would appreciate people's patience and input in that process.)

-Ian

2010/11/30 Ian Fette (イアンフェッティ) <[email-masked]>

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 30 Nov 2010 11:03:08 -0800

Ian Fette (イアンフェッティ) wrote:
> (And for the record, I am happy to put out a revision based on 
> abarth's proposal. I am also happy to try to re-write it in a format 
> that people find easier to grok, as opposed to the current handshake's 
> "read 1 byte, call it X" style. I will probably mess something up in 
> the first attempt at doing that, and would appreciate people's 
> patience and input in that process.)

If you do that, can you use a standard header format for the embedded 
request instead of the JSON? Since that JSON is going to have to be 
taken out anyway, it would be easier to start with the standard format.

If the JSON proponents can convince people the more complicated format 
adds significant value for the complexity (not likely, but conceivable I 
guess), it can be changed in an -04.

-- Scott
>
> -Ian
>
> 2010/11/30 Ian Fette (イアンフェッティ) <[email-masked] 
> <mailto:[email-masked]>>
>
>     So, can we make a decision? CCing Joe and Sal, I would like to see
>     a call for consensus.
>
>
>     On Tue, Nov 30, 2010 at 10:31 AM, Joe Mason <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         I should also mention, after seeing Adam's paper, we may
>         decide not to throw the switch on -00 after all even if
>         -03+new handshake isn't ready.  But our plan in that case will
>         still be -03+new handshake or nothing.
>
>         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.
>         [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: John Tamplin <[email-masked]>
Date: Tue, 30 Nov 2010 14:12:26 -0500

> So, can we make a decision? CCing Joe and Sal, I would like to see a call

What exactly would we be making a call for consensus on?  It seems there are
strong objectors to Adam's proposal.

I have implemented a slightly earlier version (using AES, different bogus
host header, HTTP headers instead of JSON) of Adam's proposal and it seems
to work fine.

I still have concerns about WebSocket traffic to port 80 getting through any
non-transparent proxy however, since all of the ones I have seen are
configured by default to only allow CONNECT requests to port 443.

Should we consider initially supporting only port 443?  With all the attacks
on unencrypted connections (such as Firesheep making it easy and in the
news), it wouldn't be a bad thing to avoid the problem entirely.  That would
also solve the attacks Adam saw since the proxy can't decrypt the traffic to
be confused by it, and it should make it easier to traverse such proxies
since they already work that way to allow HTTPS connections.  We could have
ws not check the certificate, while wss does, so ws wouldn't give protection
against man-in-the-middle attacks but wouldn't require the servers to have
real certificates (they could just use self-signed certs).  If we do this,
the details of the handshake are less important -- probably the v03
handshake is fine.

The downsides would be:

   - virtual hosting WebSocket connections requires TLS SNI support, which
   AFAIK means the only browser with signficant market share that doesn't
   support it is IE6
   - client-side TLS SNI support seems weak (AFAIK, there is no way for a
   Java client to support it)
   - some intermediaries may just block it if they can't filter/audit it
   - some configuration overhead on servers
   - some CPU overhead (though Google publications have indicated this is
   very low)

Is this worth proposing on the group?

---

From: "Joe Hildebrand" <[email-masked]>
Date: Tue, 30 Nov 2010 12:42:43 -0700

That's been suggested in the past, and likely won't get us to consensus quicker. 

-- 
Joe Hildebrand

On Nov 30, 2010, at 12:13 PM, "John Tamplin" <[email-masked]> wrote:

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

---

From: John Tamplin <[email-masked]>
Date: Tue, 30 Nov 2010 14:52:42 -0500

> That's been suggested in the past, and likely won't get us to consensus

In the past, we didn't have a demonstrated attack on the Upgrade
handshake, which is why I thought it might be worth bringing up.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Dec 2010 05:42:56 +0000

> handshake, which is why I thought it might be worth bringing up.
We still don't have a demonstrated attack on the Upgrade handshake.
We have a demonstrated attack on something a little bit like the Upgrade
handshake, but is essentially just sening two HTTP requests in a row, the
first with upgrade headers and then being amazed that some intermediaries
that ignore upgrade are seeing the second HTTP request.

I really do not like how this discussion is being conducted, as two many
concerns are being mixed together.

It may well be that CONNECT is better than Upgrade, but that does not mean
that we should be sending bogus host information.

It may well be that encrypting host information is necessary, but that does
not mean that we need to use CONNECT.

The two proposals should be considered separately.  We got into this
handshake mess in the first place by "accepting" a bunch of changes as a
batch when we only had concensus on a few aspects.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Dec 2010 07:16:18 +0100

> batch when we only had concensus on a few aspects.

+1

The whole work has been incremental for a long time, and suddenly we wipe
out everything and restart from scratch with new advantages and new
inconvenients. In my opinion it's a big step backwards, and the way
the issues are addressed make me feel like they're not understood so
it's better to redesign from scratch :-/

Willy

---

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

> Speaking personally, I am also in favor of Adam and Eric's proposal for a CONNECT-based handshake, as well as the associated payload masking. I expect many of my Apple colleagues would agree.

I would agree with the CONNECT handshake if we could have a correct
Host header. In my opinion, nothing prevents us from using the exact
same syntax as was used in RFC2817 for the OPTIONS method, which is
to have "*" in place of the URI to indicate the request is for the
server itself, and have the correct host information in the Host
header :

   CONNECT * HTTP/1.1
   Host: realserver.realdomain.com

A transparent proxy is less likely to interpret this as a correct
proxy request than it is with "websocket.invalid:443", and at least
we have the real Host field so that shared environments can deploy
Websocket.

> We would be hesitant to ship protocol updates that do not fix the handshake. Given the security issues identified by the paper from Adam and company, we would even consider disabling WebSocket enti…

Please note that the security issues reported in the paper were
related to the use of HTTP sometimes combined with Flash Player,
nothing was reported for Websocket. I'm not sure you want to
disable HTTP in your browser ;-)

Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 30 Nov 2010 23:20:10 -0800

> we have the real Host field so that shared environments can deploy

Perhaps CONNECT * is worth testing.

But note that a transparent proxy is rather unlikely to interpret any request for websocket.invalid:443 as a valid request, but if it does, it's guaranteed that the hostname will not resolve. RFC2606 reserves the .invalid TLD for domain names that are sure to be invalid: http://tools.ietf.org/html/rfc2606

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

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

> disable HTTP in your browser ;-)

The cost of entirely removing Flash support would be considerably higher. It's not a viable choice for desktop browsers. But in any case, it's in Adobe's power to address the vulnerability without any changes to standards.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 30 Nov 2010 23:26:07 -0800

On Nov 30, 2010, at 9:42 PM, Greg Wilkins wrote:

> We have a demonstrated attack on something a little bit like the Upgrade handshake, but is essentially just sening two HTTP requests in a row, the first with upgrade headers and then being amazed that some intermediaries that ignore upgrade are seeing the second HTTP request.

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

> 
> I really do not like how this discussion is being conducted, as two many concerns are being mixed together.
> 
> It may well be that CONNECT is better than Upgrade, but that does not mean that we should be sending bogus host information. 
> 
> It may well be that encrypting host information is necessary, but that does not mean that we need to use CONNECT.
> 
> The two proposals should be considered separately.  We got into this handshake mess in the first place by "accepting" a bunch of changes as a batch when we only had concensus on a few aspects.

It's clear that the combination of the two proposals is safer than using neither. It may be that using only one is sufficient, but no one has given strong evidence that this is so.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Dec 2010 08:41:55 +0100

> But note that a transparent proxy is rather unlikely to interpret any request for websocket.invalid:443 as a valid request, but if it does, it's guaranteed that the hostname will not resolve. RFC26…

No, it's guaranteed that such a domain will not be officially registered.
It's a lot different. It's similar to the RFC1918 addresses that must not
be routed on the net but which everyone learns on BGP from hundreds of AS.

The real issue I see with an invalid name is that it's sufficient to silently
put it in a DNS or /etc/hosts so that noone notices it, and the traffic gets
silently diverted to the host of choice. Some cheap hosting providers are
hacked several times a year, some even a few times a month, and they host
thousands of domains. One single change in their /etc/hosts immediately
allows all their hosted domains to suddenly offer a websocket service and
to be diverted to another random site.

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

I prefer something which is interpreted improperly and which does not work
than something which has chances of succeeding to the wrong place by design !

> I cannot say offhand whether CONNECT with a fake hostname (whether * or websocket.invalid) but a real Host header would be safe. I think we'd have to consider different threats than the transparent…

Well, without a proper host name, the following cannot be done anymore :

  - URL filtering (mobile gateways, schools, ISPs)
    This introduces a new major security concern

  - Websocket for everyone : while Hixie wanted Websocket to be for the
    masses, now we're turning to Websocket for the Elite : you will
    need to have your own IP address to be able to run Websocket. That's
    completely opposite to the directions taken by the HTTP WG which want
    to incite IP address sharing.

  - Host-based transparent proxying : In his paper, Adam explained how some
    transparent HTTP proxies route based on the destination IP address instead
    of using the Host header. We all know that using the destination IP address
    is dangerous because it makes it easy to bypass filtering rules and/or to
    corrupt caches. If websocket does not provide a valid routing information,
    the only information transparent proxies will be able to use is precisely
    the destination IP address, which will become an incentive for doing that
    again.

> The cost of entirely removing Flash support would be considerably higher. It's not a viable choice for desktop browsers. But in any case, it's in Adobe's power to address the vulnerability without…

I don't know who's responsible for how the sockets are used/reused, as I'm
not aware of internal browser architecture. But anyway some of the issues
in the paper only involve pure HTTP and dirty transparent proxies. So we're
trying to protect from issues that already exist on HTTP itself, which will
not improve anything.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Dec 2010 08:43:41 +0100

> it's better to redesign from scratch :-/

Agreed.

Best regards, Julian