Subject: [hybi] Experiment comparing Upgrade and CONNECT handshakes

From: Adam Barth <[email-masked]>
Date: Fri, 26 Nov 2010 15:48:16 -0800

David Huang, Eric Chen, Eric Rescorla, Collin Jackson, and I have been
experimenting with the security of the Upgrade-based and CONNECT-based
WebSocket handshakes.  Please find a paper detailing our findings at
this location:

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

== Summary ==

The Upgrade-based handshake is vulnerable to attack in network
configurations involving transparent (or intercepting) proxies.  The
core issue is that some number of transparent proxies do not
understand the HTTP Upgrade mechanism and therefore don't understand
that the remaining bytes sent by the attacker on the socket are not
HTTP.  These proxies treat these bytes as subsequent HTTP requests,
letting the attacker either circumvent firewalls or, worse, poison the
proxy's HTTP cache (depending on how the proxy is configured).  Please
see the paper for details about how these attacks work.

To demonstrate that these attacks work in practice and to estimate how
many users are vulnerable to attack, we ran an experiment on the
Internet using a rich-media advertisement.  We found that for a $100,
we were able to poison the cache of 8 users by using the Upgrade-based
handshake.  When the attacker is able to poison the proxy's cache in
this way, the attacker can exploit /every/ user of the cache, with
potentially dangerous consequences.  For example, the attacker can
poison the proxy's cache entry for
http://www.google-analytics.com/ga.js and inject JavaScript into
approximately 57% of the top 10,000 web sites.

We attempted to mount the same class of attack against the
CONNECT-based handshake.  We were unable to poison any proxy caches
when using the CONNECT-based handshake.  Based on the data we've
collected, vastly most proxies appear to understand the semantics of
CONNECT requests than understand the semantics of the Upgrade
mechanism.  This is consistent with our prior beliefs because CONNECT
is widely used on the Internet to tunnel TLS through proxies whereas
Upgrade is used rarely.

== Recommendation ==

We recommend that the working group adopt the CONNECT-based handshake
described in draft-abarth-websocket-handshake rather than an
Upgrade-based handshake.  Empirically speaking, the CONNECT-based
handshake avoids the real-world attacks we have demonstrated against
Upgrade-based handshakes, requires no more round trips, success
approximately as often, and complies with HTTP.

Kind regards,
Adam

---

From: Adam Barth <[email-masked]>
Date: Fri, 26 Nov 2010 17:14:55 -0800

On Fri, Nov 26, 2010 at 4:55 PM, Greg Wilkins <[email-masked]> wrote:
> on the whole, your paper looks like excellent work and I think you have
> discovered a existing vulnerability  which obviously needs to be fixed.

Thanks.

> With regards to websocket, your paper says:
>   " Our advertisement contains a SWF which performs the WebSocket handshake,
> spoofs an HTTP request upon handshake success,..."
>
> Was the spoofed HTTP request framed as a websocket frame?

Nope.  It's the handshake's job to establish that it's safe to let the
attacker to communicate on the socket.

> Would it be possible for you to repeat the experiment, but with the framing
> changes proposed to make WS frames less likely to be interpreted as HTTP (ie
> flipping the sense of the more bit). Also it would be interesting to see if
> the exchange of HELLO frames after the handshake had an effect on
> transparent proxies.

The exchange of HELLO frames adds an extra round-trip.  There's no
need to delay the connection with an extra round trip.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Nov 2010 15:29:55 +1100

> attacker to communicate on the socket.

Adam,

well I don't want to detract from your findings, which I think are
significant in terms of how intermediaries behave in relation to spoofed
host headers on connections.... but I think that not framing the websocket
content does detract significantly from your findings regarding websocket
handshakes.

You have shown that unfettered raw access to a socket after an upgrade does
result in significant exploitable vulnerabilities.  However, unlike swf or
java, websocket does not propose to give applications unfettered raw access
to the socket.

One of the reasons expressed that websocket should use framing is that it
was considered unsafe to have free access to a socket, even after a
handshake, for reasons like the vulnerability you have highlighted. Framing
can prevent user supplied content looking like HTTP requests, plus there are
some proposals that further harden framing against such spoofing.  Also the
Hello proposal (which does not involved an extra round trip) offers further
protection.

So by not including the framing (existing or enhanced) you are testing an
artificial situation, finding it vulnerable and exploitable, and then
concluding that websockets is vulnerable and exploitable.  I think this is
over stating the case against websockets use of upgrade and ignoring the
proposals already made to protect against this kind of vulnerability.   I
think we should also wait to see how the wider problems you have highlighted
are addressed before concluding that Upgrade is fatally flawed (which still
may be the final conclusion).

regards

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Nov 2010 22:16:45 -0800

> java, websocket does not propose to give applications unfettered raw access

Well, in every existing proposal, it proposes to give them control over the
vast majority of
bytes on the socket, with some uncontrollable, but predictable framing. In
order for this to
be exploitable, you primarily need a proxy which is willing to ignore
malformed requests
enough to allow the attacker to resynchronize.

It's true that we don't have a demonstrated exploit against such a proxy and
exactly
what's required in order to mount such an exploit is probably somewhat
implementation-
specific. However, I'm unaware of any convincing security analysis that
demonstrates
that the framing is a serious obstacle.

> may be the final conclusion).

I don't really understand where you are going with this.

Adam's argument throughout the discussion has been that we ought to build a
system out of
components that are demonstrably secure. To me, that means that the
handshake ought to
be as secure as we can make it and depend to the minimal amount possible on
heuristic
arguments about the difficulty of exploiting other pieces of the system.

Our measurements indicate that some existing proxies get confused when
confronted with
the -76 handshake [and it's not clear to me that your proposed handshake
will behave
any better, since it looks to the proxy like the original -76 handshake
followed by a bunch
of opaque bytes, which is what the existing -76 handshake looks like. If
that doesn't
work, then it's likely that the system will just fail.]That leaves us with
the primary
defense being the difficulty of resynchronizing the framing, which, as I
said, depends
on assumptions about how error tolerant the proxy is.

By contrast, the handshake which Adam and I have described has comparable
measured success rates in the field coupled with measurably better (though
not
provably ideal) in terms of the extent to which it confuses proxies, even
without the
improved masking we describe in Sectiion V(C)(3).

I don't think the relevant question is really--as your message
implies--whether the
Upgrade handshake is fatally flawed, but rather what the best design is. I
think it's
pretty clear that the design Adam and I proposed has better arguments for
security,
so the question is whether there are countervailing factors.

As I understand it, your preference for the Upgrade-based handshake is based
on
the argument that it's more compatible with existing web infrastructure. As
far as
I can tell, that compatibility is based on two features:

(1) the use of a method other than CONNECT.
(2) the use of a non-bogus Host header.

Your existing proposal abandons aspect #1 in favor of WEBSOCKET, so this
leaves us with the non-bogus Host header which is precisely the feature that
our
study has found to be problematic.

Given that, it's not clear to me what the arguments against the
CONNECT-based
handshake are.

Best,
-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 27 Nov 2010 08:16:44 +0100

Hi Eric,

> enough to allow the attacker to resynchronize.

I can't agree with you on this Eric, because your study relies on broken
components that act as you want depending on the test. For instance, there
is the following paragraph concerning the POST-based handshake which is
wrong :

  Consider an intermediary examining packets exchanged
  between the browser and the attacker's server. As above,
  the client requests WebSockets and the server agrees. At
  this point, the client can send any traffic it wants on the
  channel. Unfortunately, the intermediary does not know about
  WebSockets, so the initial WebSockets handshake just looks
  like a standard HTTP request/response pair, with the request
  being terminated, as usual, by an empty line. Thus, the client
  program can inject new data which looks like an HTTP request
  and the proxy may treat it as such. So, for instance, he might
  inject the following sequence of bytes:

It assumes that an intermediary can accept a new HTTP request on
a non-keep-alive response. This does not work, this is not even
remotely looking like HTTP. The intermediary needs a content-length,
a transfer-encoding or a method or status code which implies an
empty body to be able to accept a second request. Here we have a
POST and a 200. Without either a content-length or a tranfer-encoding,
it is the last response and the response goes till the end of the
connection.

This is not even implementation-specific, such a compontent cannot
work without that.

It's important to keep the basic semantics of the HTTP protocol in
mind when addressing the handshake issues, because I once again feel
like we're trying to invent imaginary components for every type of
handshake that has to be dismissed. We could as well invent an imaginary
proxy that badly fails on the CONNECT handshake.

> that the framing is a serious obstacle.

Please keep in mind that both the handshake and the framing are important.
Without a proper handshake, we could easily trick an existing proxy into
caching the first response as a wrong one, or perform cross-protocol
connections. The framing is important to prevent the situations where
intermediaries could have been mistaken by the handshake from confusing
raw data with some protocol they speak.

It has been said several times, but designing a keep-alive compatible
proxy really is tough work and requires to respect some key points of
HTTP, particularly the messaging. In order to be deployed, the component
does not have to be safe, but it has to work for the most common situations.
This means that we're sure to find proxies that don't work with 101 responses,
that do not correclty handle multiple content-length, that accept any raw data
in header names etc... (eg: apache has all these flaws but it's one of the
most commonly deployed reverse-proxies). But the component must flawlessly
work on the most common traffic. Basically, handling a POST with a 200 and
supporting correct messaging (ie respecting a missing or a correctly-formed
content-length header) is essential.

This means that if the framing ensures that :
  - initial data sent from the client to the server cannot be parsed as a
    valid HTTP request
  - initial data sent from the server to the client cannot be parsed as a
    valid HTTP response

then we have something that cannot fool these components. For instance, we
could very well have a POST and a 200 both containing a Content-length: 1 gig
and have a safe channel for us for the first gig of data. This would be stupid
because many proxies will not necessarily let the client-to-server data pass
once the server responds. But still it shows why HTTP messaging is important.

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

That's why I'm saying that both handshake and framing are important and
that we must not ignore reality. It's nice to invent imaginary components
to see how an issue or another could lead to an exploitable situation, but
at one point, it is important to weigh the degree of imagination when drawing
to a conclusion.

I'm not dismissing your work nor am I against the use of the CONNECT method,
indeed I was one of the first to ask for it several months ago. I'm just
trying to ensure that we focus on real world tests with both handshake and
framing trying to do the right thing and being usable by intermediaries as
appropriate.

For example, in your case, the whole security of the CONNECT-based method
relies on the fact that "websocket.invalid" cannot be resolved. Have you
imagined that future malware will try to add their own IP address in front
of "websocket.invalid" in every etc/hosts so that they can try to divert
most of the leaking requests ?

  root@pcw:~# echo "127.0.0.1 websocket.invalid" >> /etc/hosts
  root@pcw:~# ping websocket.invalid
  PING websocket.invalid (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.022 ms
  ^C

It would even be enough to couple that with DNS poisoning attacks, because
surely some proxies will try to resolve it via the DNS :

  willy@pcw:~$ host -a websocket.invalid
  Trying "websocket.invalid"
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52408
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;websocket.invalid.             IN      ANY

  ;; ANSWER SECTION:
  websocket.invalid.      3600    IN      CNAME   www.attacker.com.

I'd rather have something which works by protocol construction than by
pure luck because hopefully nobody resolves websocket.invalid.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Nov 2010 21:51:38 +1100

> I don't really understand where you are going with this.

Eric,

all I'm saying is that the paper has over stated the case against the
websocket upgrade handshake.    It is written as if an exploit has
been found in websocket, when if fact it was an experiment that really
just sent two HTTP requests one after the other, with the first having
Upgrade headers that were ignored.

I think the findings of how some intermediaries are treating the host
headers are indeed a very significant finding, but I don't think it
does the argument any favours to overstate the resulting conclusions.

It may well be that this issue is sufficient to sway us from Upgrade
to Connect, I for one am certainly re-evaluating my position.   But it
is not a slam dunk as it has been presented, as it may be that
framing, flipped bits and HELLO frames may be sufficient to prevent
this vulnerability for the vulnerable intermediaries.

> confronted with the -76 handshake

Was the experiment conducted with the full -76 handshake including the
random bytes after the request and response?  If so were you able to
collect the actual random bytes sent/received to see if they were all
within ASCII range.

> That leaves us with the primary

Indeed this is a thinning defence and I don't dispute that.    But I
do think the paper should acknowledge that this defence does exist.
Over stating the exploit does no favours to the argument against
upgrade.

It well may be that this defence is too thin, but this needs to be
determined by analysis not assumption.  We also need to consider the
defence can be improved or other defences created.
Obviously we also need to consider CONNECT.

> Given that, it's not clear to me what the arguments against the

Well I've not be talking against the CONNECT based handshake in this
thread.  I've just been enquiring about exactly how websocket-like the
experiment was and expressing a concern that the exploit has been
overstated.  The overstatement is unfortunate as we are now discussing
the overstatement instead of the significant real vulnerability that
was found.

But since you ask, my concern about CONNECT in general is that it may
be limited to ports that it will work for, but that might be the least
of our problems.  My concern about your specific CONNECT proposal is
as you say, about the bogus host headers.

I can't see how the bogus host headers reduce the vulnerability in
this case, because it is the fake host headers in the data stream that
the intermediaries are seeing and resulting in the poisoned caches.
If we made the host header in the upgrade request bogus, I don't think
it would protect against this issue.      I suspect that it is the
CONNECT that is the defence in this case and not the bogus hosts - but
I'll try to find the time to conduct some experiments to check that.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Nov 2010 11:55:51 +1100

Adam,

regards

On 27 November 2010 10:48, Adam Barth <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Nov 2010 07:51:17 -0800

> it is the last response and the response goes till the end of the

Remember that you're talking to the attacker's server. That server generates
a 200 with a content length of 0. And since requests without content-length
are assumed to be empty, this is completely compliant.

> proxy that badly fails on the CONNECT handshake.

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

> Please keep in mind that both the handshake and the framing are important.

Yes, which is why we have *also* proposed a superior masking mechanism.

> connections.

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

> whatever the handshake, it's really the framing that's protecting you.
These sound to me like heuristic defenses to protect you from the handshake
being
insecure. What's the argument *for* having an insecure handshake?

> at one point, it is important to weigh the degree of imagination when

You keep saying we're inventing components, but we're not. These are
measurements
conducted in the field with components that we have no control over.

>  websocket.invalid.      3600    IN      CNAME   www.attacker.com.
Both of these attacks are outside the Web threat model and enable much more
serious attacks than WebSockets. In particular:

1. If I can modify /etc/hosts (which typically requires root privileges) I
can inject
any malware of my choice onto the machine.
2. If I can poison DNS, then I can mount cache attacks directly.

> pure luck because hopefully nobody resolves websocket.invalid.

It's not luck that people don't resolve websocket.invalid. However, we would
certainly be willing to choose another bogus Host header that people had
more confidence in, if that's somehow a sticking point.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 27 Nov 2010 17:16:38 +0100

> are assumed to be empty, this is completely compliant.

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

> kind of proxy that can fail. We're observing such proxies in the field.

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

> appear to be rather more susceptible to this when Upgrade is used then

Once again, I'm not surprized at all.

> being insecure.

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

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

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

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

> can inject any malware of my choice onto the machine.

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

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

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

> more confidence in, if that's somehow a sticking point.

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

Regards,
Willy

---

From: Adam Barth <[email-masked]>
Date: Sat, 27 Nov 2010 08:24:15 -0800

On Sat, Nov 27, 2010 at 8:16 AM, Willy Tarreau <[email-masked]> wrote:
> for having a safe HTTP-compliant handshake.

The handshake we're proposing is both safe and HTTP compliant.

Kind regards,
Adam

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sat, 27 Nov 2010 08:32:55 -0800

> The handshake we're proposing is both safe and HTTP compliant.
I really appreciate all the work you and others have done with this paper. I
have a few questions I'd like to ask if you wouldn't mind.

#1, if we changed the non-bogus Host header to be the real host, do you
believe that would have any substantial negative impact?
#2 Is there anything else that is in the handshake proposal that is perhaps
HTTP compliant by the letter but not the spirit? (Other than CONNECT vs
UPGRADE -- I think you've made that case.)

I personally don't care strongly enough about the above to call them a
requirement, but a number of people on this list have raised the HTTP compat
issue so I would like to better understand what that would imply with the
proposal this paper suggests the group move forward with.

-Ian

---

From: Adam Barth <[email-masked]>
Date: Sat, 27 Nov 2010 08:56:37 -0800

> believe that would have any substantial negative impact?

We didn't run that experiment, so I can't say for sure, but my
impression is that it would not have a substantial negative impact.
That mitigation is for the virtual hosting scenario where one virtual
host might accept the handshake on behalf of the whole physical host.
These attacks are, of course, much more expensive to mount than the
attacks described in the paper, which are quite cheap.

> proposal this paper suggests the group move forward with.

We've moved some of the bits around since the first draft to make the
handshake HTTP compliant.  For example, we used to send the metadata
in the entity body, but HTTP forbids CONNECT requests from having an
entity body, so we now send the data in a header.  I don't know of
anything in the current proposal that violates HTTP.  If folks point
out specific aspects they believe are in violation, I'm sure we can
find a way to fix them.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 27 Nov 2010 18:38:12 +0100

> The handshake we're proposing is both safe and HTTP compliant.

So I can use the Host header to route it through a shared infrastructure
and deliver the connect request to the appropriate server ? I'm not so
sure...

Regards,
Willy

---

From: Scott Ferguson <[email-masked]>
Date: Sat, 27 Nov 2010 22:00:25 -0800

Ian Fette (イアンフェッティ) wrote:
> On Sat, Nov 27, 2010 at 8:24 AM, Adam Barth <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Sat, Nov 27, 2010 at 8:16 AM, Willy Tarreau <[email-masked]
>     <mailto:[email-masked]>> wrote:
> I really appreciate all the work you and others have done with this 
> paper. I have a few questions I'd like to ask if you wouldn't mind.
>
> #1, if we changed the non-bogus Host header to be the real host, do 
> you believe that would have any substantial negative impact?
> #2 Is there anything else that is in the handshake proposal that is 
> perhaps HTTP compliant by the letter but not the spirit? (Other than 
> CONNECT vs UPGRADE -- I think you've made that case.)
>
> requirement, but a number of people on this list have raised the HTTP 
> compat issue so I would like to better understand what that would 
> imply with the proposal this paper suggests the group move forward with.

The change of the CONNECT URI to the known host "websocket.invalid" 
makes a difference, because a server can dispatch the known 
"websocket.invalid" host to a websocket handler. (The earlier scrambling 
of the URI was unworkable.)

In other words, there's a difference between a well-known 
"websocket.invalid" host and a bogus host. A truly bogus host would be a 
problem (and wouldn't be HTTP in any meaningful way).

That's from the end-server perspective. I don't know about proxies, 
although I'd think a websocket-aware proxy could unpack the embedded URL 
and forward based on it.

-- Scott

>
> -Ian 
> ------------------------------------------------------------------------
>

---

From: John Tamplin <[email-masked]>
Date: Sun, 28 Nov 2010 03:04:01 -0500

> Hello proposal (which does not involved an extra round trip) offers further

Note that adding Hello frames or arbitrary other verification that a
real WebSocket client is connecting doesn't help -- in this attack
scenario, the attacker is running their JS code in the browser and
their code on the server, and it sets up a real WebSocket connection.
Unless the payload is masked, you have to rely on the handshake and
framing ensuring that a transparent proxy doesn't accept WebSocket
payload content as if it were an HTTP request.  Also note that since
the attacker controls the server, they can add extra headers to the
Upgrade response which will be ignored by the WebSocket client but may
confuse the transparent proxy.

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

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 28 Nov 2010 19:44:52 +1100

> their code on the server, and it sets up a real WebSocket connection.

John,

I think this is an assumption that needs to be tested.

The vulnerability results because the intermediary is interpreting every
HTTP request on the stream.  If Hello frames are sent, or the fake HTTP
requests are encapsulated in WS frames, then that may be sufficient to
disrupt the parsing that the intermediaries are doing.

Note that I agree with Eric when he says that this defence is reliant on the
intermediary not being able to re-establish HTTP framing after non HTTP
bytes are sent and that this might be rather a rather thin defence.   But
there still may be things that can be done to create better defences.

cheers

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 09:31:57 -0800

On Sat, Nov 27, 2010 at 10:00 PM, Scott Ferguson <[email-masked]> wrote:
>> I really appreciate all the work you and others have done with this paper.
>> I have a few questions I'd like to ask if you wouldn't mind.
>>
>> perhaps HTTP compliant by the letter but not the spirit? (Other than CONNECT
>> vs UPGRADE -- I think you've made that case.)
>>
> The change of the CONNECT URI to the known host "websocket.invalid" makes a
> difference, because a server can dispatch the known "websocket.invalid" host
> to a websocket handler. (The earlier scrambling of the URI was unworkable.)

This change is already incorporated in the current version of
draft-abarth-websocket-handshake.

> That's from the end-server perspective. I don't know about proxies, although
> I'd think a websocket-aware proxy could unpack the embedded URL and forward
> based on it.

Great.  I'm glad it works for you.

Adam

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 29 Nov 2010 09:44:22 -0800

> draft-abarth-websocket-handshake.

This really shows the disadvantage of the "procedural" style of spec
writing. By obfuscating the intention of the spec, you make it difficult
to see changes or to evaluate what the proposal is doing.

And, bluntly, not many people have the time to wade through and decode
the obfuscating junk.

-- Scott

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Nov 2010 19:23:05 +0100

On 27.11.2010 00:48, Adam Barth wrote:
> ...

Very interesting stuff.

How about:

1) Installing a permanent test service which would allow people to check 
whether they have broken intermediaries in the path, and then

2) Re-run the experiment again at a later point.

Also:

3) Stop shipping implementations of the so-called "76" protocol; we 
know, that the current version performs better because of the framing, 
right?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 10:24:11 -0800

> to see changes or to evaluate what the proposal is doing.

Indeed.  We should be able to get all the editorial issues sorted out
once we've got consensus on the technical issues.  For the time being,
draft-abarth-websocket-handshake just matches the editorial style of
the corresponding section of draft-ietf-hybi-thewebsocketprotocol.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 10:28:47 -0800

> whether they have broken intermediaries in the path, and then

We did this for the DNS rebinding work, but it didn't turn out to be
that valuable.  These services have a lot of moving parts and tend to
break down if not actively maintained.  Generally, we haven't found
that folks have enough motivation to actively maintain these services,
which is why we write papers that describe the issues in enough detail
that other folks can reproduce our results independently.

> 2) Re-run the experiment again at a later point.

I'm not sure what the point of that would be, but if there's interest,
we might re-run the experiment in five years to see what happened.

> Also:
>
> 3) Stop shipping implementations of the so-called "76" protocol; we know,
> that the current version performs better because of the framing, right?

AFAIK, everyone who has shipped the 76 protocol has stated their
intention to upgrade to the final version of the protocol.  Hopefully
we'll be able to settle the handshake issue and finish up the spec
soon.

Adam

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 29 Nov 2010 10:48:03 -0800

> the corresponding section of draft-ietf-hybi-thewebsocketprotocol.

You're missing the point.

It's hard to evaluate the proposal for technical purposes the way you've 
written it. Many of the people on this list, including me, are very busy 
people and really don't have the time to wade through a proposal that's 
deliberately written in an obfuscatory fashion.

The problem has nothing to do with the final language; it's about 
communicating proposals for the people on this list.

-- Scott

---

From: Brian <[email-masked]>
Date: Tue, 30 Nov 2010 15:03:03 -0800

Adam, since it's been a while and I've lost the link to the new
handshake proposal, can you verify for me (and others) that this is
the most up-to-date version that I should be reading?

http://tools.ietf.org/html/draft-abarth-websocket-handshake-01

Thanks,
Brian McKelvey
Worlize, Inc.

---

From: Adam Barth <[email-masked]>
Date: Tue, 30 Nov 2010 15:27:16 -0800

That's the most up-to-date version.

Adam

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Barth
> Sent: Tuesday, November 30, 2010 6:27 PM
> To: Brian
> Cc: Hybi
> Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
> 

I noticed that version uses XOR for masking, while your paper mentioned using AES.  Are you planning to update this proposal to use AES as well?  (Also, now that I've read the thing, here's another vote for rewriting it in declarative style.)

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 19:31:01 -0500

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

> I noticed that version uses XOR for masking, while your paper mentioned
> using AES.  Are you planning to update this proposal to use AES as well?
>  (Also, now that I've read the thing, here's another vote for rewriting it
> in declarative style.)
>

It was changed to XOR following feedback that since it wasn't for security
purposes (as the key would be known to an eavesdropper), there was little
point in additional complexity and dependencies (and more things to go
wrong, such as how you configure it) to use AES rather than XOR.

---

From: Adam Barth <[email-masked]>
Date: Tue, 30 Nov 2010 16:52:51 -0800

> I noticed that version uses XOR for masking, while your paper mentioned using AES.  Are you planning to update this proposal to use AES as well?  (Also, now that I've read the thing, here's another…

The paper describes what we believe to be the best handshake.
draft-abarth-websocket-handshake represents a sequence of compromises
we've made with this working group.  It seems likely we'll compromise
more as time goes on.  As such, draft-abarth-websocket-handshake is
the "most up-to-date" version.

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 30 Nov 2010 18:58:08 -0800

> I noticed that version uses XOR for masking, while your paper mentioned using AES.  Are you planning to update this proposal to use AES as well?  (Also, now that I've read the thing, here's another…

The syntax can perhaps be described declaratively, but some parts will likely have to remain algorithmic. There are specific computations to be done with the fields and particular must-reject conditions which are essential to the security of the handshake. Computing the values of certain fields in the syntax also needs to be done in a particular way, for instance the fact that the client-nonce is to be chosen uniformly at random each time is important, and not really captured by ABNF.

Regards,
Maciej

---

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

On Tue, Nov 30, 2010 at 6:58 PM, Maciej Stachowiak <[email-masked]> wrote:

> The syntax can perhaps be described declaratively, but some parts will
> likely have to remain algorithmic. There are specific computations to be
> done with the fields and particular must-reject conditions which are
> essential to the security of the handshake. Computing the values of certain
> fields in the syntax also needs to be done in a particular way, for instance
> the fact that the client-nonce is to be chosen uniformly at random each time
> is important, and not really captured by ABNF.
>
> Regards,
> Maciej
>
>
Maciej, I agree with you that some parts will have to remain algorithmic,
e.g. some of the rejection conditions and calculations. I'm hoping we can
find a happy medium somewhere, and I will not take it at all personally if
people have suggested changes once we have a draft to change (assuming we
can declare consensus that this is the handshake we want to move forward
with, which I hope we can.)