Discussion:
[hybi] Experiment comparing Upgrade and CONNECT handshakes
Adam Barth
2010-11-26 23:48:16 UTC
Permalink
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
Adam Barth
2010-11-27 01:14:55 UTC
Permalink
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.
  " 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
Greg Wilkins
2010-11-27 04:29:55 UTC
Permalink
Post by Adam Barth
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.
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
Eric Rescorla
2010-11-27 06:16:45 UTC
Permalink
Post by Greg Wilkins
Post by Adam Barth
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.
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.
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.



So by not including the framing (existing or enhanced) you are testing an
Post by Greg Wilkins
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).
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
Willy Tarreau
2010-11-27 07:16:44 UTC
Permalink
Hi Eric,
Post by Eric Rescorla
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.
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.
Post by Eric Rescorla
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.
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 ?

***@pcw:~# echo "127.0.0.1 websocket.invalid" >> /etc/hosts
***@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 :

***@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
Eric Rescorla
2010-11-27 15:51:17 UTC
Permalink
Post by Willy Tarreau
Hi Eric,
Post by Eric Rescorla
Well, in every existing proposal, it proposes to give them control over
the
Post by Eric Rescorla
vast majority of
bytes on the socket, with some uncontrollable, but predictable framing.
In
Post by Eric Rescorla
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.
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
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
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.
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.
Post by Willy Tarreau
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.
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.
Post by Willy Tarreau
Post by Eric Rescorla
It's true that we don't have a demonstrated exploit against such a proxy
and
Post by Eric Rescorla
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.
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.
Post by Willy Tarreau
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.
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.



It has been said several times, but designing a keep-alive compatible
Post by Willy Tarreau
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.
- 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.
These sound to me like heuristic defenses to protect you from the handshake
being
insecure. What's the argument *for* having an insecure handshake?
Post by Willy Tarreau
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.
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.
Post by Willy Tarreau
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 ?
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
Trying "websocket.invalid"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52408
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;websocket.invalid. IN ANY
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.


I'd rather have something which works by protocol construction than by
Post by Willy Tarreau
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
Willy Tarreau
2010-11-27 16:16:38 UTC
Permalink
Post by Eric Rescorla
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.
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.
Post by Eric Rescorla
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.
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.
Post by Eric Rescorla
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.
Once again, I'm not surprized at all.
Post by Eric Rescorla
Post by Willy Tarreau
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.
These sound to me like heuristic defenses to protect you from the handshake
being insecure.
No, those are defenses against the intermediaries that may unexpectedly
think framed data are new requests.
Post by Eric Rescorla
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.
Post by Eric Rescorla
Both of these attacks are outside the Web threat model and enable much more
1. If I can modify /etc/hosts (which typically requires root privileges) I
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).
Post by Eric Rescorla
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.
Post by Eric Rescorla
I'd rather have something which works by protocol construction than by
Post by Willy Tarreau
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.
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
Adam Barth
2010-11-27 16:24:15 UTC
Permalink
Post by Willy Tarreau
Post by Eric Rescorla
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 handshake we're proposing is both safe and HTTP compliant.

Kind regards,
Adam
Ian Fette (イアンフェッティ)
2010-11-27 16:32:55 UTC
Permalink
Post by Eric Rescorla
Post by Willy Tarreau
Post by Eric Rescorla
What's the argument *for* having an insecure handshake?
There's no argument *for* having an insecure handshake, there are
arguments
Post by Willy Tarreau
for having a safe HTTP-compliant handshake.
The handshake we're proposing is both safe and HTTP compliant.
Kind regards,
Adam
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
Adam Barth
2010-11-27 16:56:37 UTC
Permalink
Post by Ian Fette (イアンフェッティ)
Post by Adam Barth
Post by Willy Tarreau
Post by Eric Rescorla
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 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?
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.
Post by Ian Fette (イアンフェッティ)
#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.
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
Scott Ferguson
2010-11-28 06:00:25 UTC
Permalink
Post by Willy Tarreau
Post by Willy Tarreau
Post by Eric Rescorla
What's the argument *for* having an insecure handshake?
There's no argument *for* having an insecure handshake, there
are arguments
Post by Willy Tarreau
for having a safe HTTP-compliant handshake.
The handshake we're proposing is both safe and HTTP compliant.
Kind regards,
Adam
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.
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
Post by Willy Tarreau
-Ian
------------------------------------------------------------------------
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Adam Barth
2010-11-29 17:31:57 UTC
Permalink
Post by Willy Tarreau
Post by Willy Tarreau
Post by Eric Rescorla
What's the argument *for* having an insecure handshake?
There's no argument *for* having an insecure handshake, there
are arguments
Post by Willy Tarreau
for having a safe HTTP-compliant handshake.
The handshake we're proposing is both safe and HTTP compliant.
Kind regards,
Adam
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.
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.
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.
Great. I'm glad it works for you.

Adam
Scott Ferguson
2010-11-29 17:44:22 UTC
Permalink
Post by Adam Barth
Post by Willy Tarreau
Post by Willy Tarreau
Post by Eric Rescorla
What's the argument *for* having an insecure handshake?
There's no argument *for* having an insecure handshake, there
are arguments
Post by Willy Tarreau
for having a safe HTTP-compliant handshake.
The handshake we're proposing is both safe and HTTP compliant.
Kind regards,
Adam
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.
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.
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
Post by Adam Barth
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.
Great. I'm glad it works for you.
Adam
Adam Barth
2010-11-29 18:24:11 UTC
Permalink
Post by Scott Ferguson
Post by Adam Barth
This change is already incorporated in the current version of
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.
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
Scott Ferguson
2010-11-29 18:48:03 UTC
Permalink
Post by Adam Barth
Post by Scott Ferguson
Post by Adam Barth
This change is already incorporated in the current version of
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.
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.
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
Post by Adam Barth
Adam
Brian
2010-11-30 23:03:03 UTC
Permalink
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.
Post by Scott Ferguson
Post by Scott Ferguson
Post by Adam Barth
This change is already incorporated in the current version of
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.
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.
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
Adam
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Adam Barth
2010-11-30 23:27:16 UTC
Permalink
That's the most up-to-date version.

Adam
Post by Brian
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.
Post by Scott Ferguson
Post by Scott Ferguson
Post by Adam Barth
This change is already incorporated in the current version of
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.
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.
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
Adam
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Joe Mason
2010-12-01 00:16:44 UTC
Permalink
-----Original Message-----
Adam Barth
Sent: Tuesday, November 30, 2010 6:27 PM
To: Brian
Cc: Hybi
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
That's the most up-to-date version.
Adam
Post by Brian
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
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.
John Tamplin
2010-12-01 00:31:01 UTC
Permalink
Post by Joe Mason
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.
--
John A. Tamplin
Software Engineer (GWT), Google
Adam Barth
2010-12-01 00:52:51 UTC
Permalink
-----Original Message-----
Adam Barth
Sent: Tuesday, November 30, 2010 6:27 PM
To: Brian
Cc: Hybi
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
That's the most up-to-date version.
Post by Brian
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
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.)
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
Maciej Stachowiak
2010-12-01 02:58:08 UTC
Permalink
Post by Joe Mason
-----Original Message-----
Adam Barth
Sent: Tuesday, November 30, 2010 6:27 PM
To: Brian
Cc: Hybi
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
That's the most up-to-date version.
Adam
Post by Brian
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
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.)
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
Ian Fette (イアンフェッティ)
2010-12-01 04:37:24 UTC
Permalink
Post by Joe Mason
Post by Joe Mason
-----Original Message-----
Adam Barth
Sent: Tuesday, November 30, 2010 6:27 PM
To: Brian
Cc: Hybi
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
That's the most up-to-date version.
Adam
Post by Brian
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
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.)
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.)
Post by Joe Mason
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Willy Tarreau
2010-11-27 17:38:12 UTC
Permalink
Post by Adam Barth
Post by Willy Tarreau
Post by Eric Rescorla
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 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
Greg Wilkins
2010-11-27 10:51:38 UTC
Permalink
Post by Eric Rescorla
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.
Post by Eric Rescorla
Our measurements indicate that some existing proxies get confused when
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.
Post by Eric Rescorla
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.
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.
Post by Eric Rescorla
Given that, it's not clear to me what the arguments against the
CONNECT-based
handshake are.
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.
John Tamplin
2010-11-28 08:04:01 UTC
Permalink
Post by Greg Wilkins
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.
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
Greg Wilkins
2010-11-28 08:44:52 UTC
Permalink
Post by John Tamplin
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.
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
Post by John Tamplin
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
Greg Wilkins
2010-11-27 00:55:51 UTC
Permalink
Adam,

on the whole, your paper looks like excellent work and I think you have
discovered a existing vulnerability which obviously needs to be fixed.

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?

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.

regards
Post by Adam Barth
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
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
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Julian Reschke
2010-11-29 18:23:05 UTC
Permalink
Post by Adam Barth
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
http://www.adambarth.com/experimental/websocket.pdf
...
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
Adam Barth
2010-11-29 18:28:47 UTC
Permalink
Post by Julian Reschke
Post by Adam Barth
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
http://www.adambarth.com/experimental/websocket.pdf
...
Very interesting stuff.
1) Installing a permanent test service which would allow people to check
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.
Post by Julian Reschke
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.
Post by Julian Reschke
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
Zhong Yu
2010-12-01 03:33:50 UTC
Permalink
With Upgrade handshake, only 1 (out of 50K) firewall circumvention
attack was successful. While with POST/Java/Flash, the number is
around 1000. The Upgrade handshake is a huge improvement! But why? I
assume that the random bytes and framing bytes in the -76 handshake
corrupted HTTP streams and busted 99.9% of HTTP parsers.

In the singular successful case, the transparent proxy ignored these
non-http bytes and constructed a http request anyway, at least, it
extracted the "Host" header. For this attack to be really useful, it's
not enough that the bytes are tunneled to target.com. The proxy must
strip non-http bytes and send a compliant http request to target.com.
Or, the proxy forwards all bytes to target.com, and target server
strips non-http bytes and reconstructs the intended http request. Did
one of these two things actually happened in the experiment?

Even worse for the attacker, it's highly unlikely that the http
response sent back by target.com will be accepted by the WebSocket
client as valid WebSocket stream. If the attacker cannot read the
response from target.com, this attack is less useful than sending a
simple HTTP request.

The combined odds that this attack works over Upgrade handshake is
extremely small.

With CONNECT handshake the same transparent proxy did not pass through
the firewall circumvention attack. It is very likely that the proxy
routes by Host for each request. The handshake contains an invalid
Host, the routing failed, the connection was aborted, and the attack
couldn't be carried out. Most likely CONNECT wins over Upgrade on this
single case because of the bogus Host header, not because the proxy
understands CONNECT and gives up parsing the rest of stream.

Altering the semantics of Host is a big deal. Even though it turns out
to be "helpful" in this singular case of the experiment, the price far
more exceeds the benefit.

It should be stressed that the paper contains no empirical evidence
that the bogus Host would be helpful in other threat models.

If Host really is a problem, we should simply remove it from
handshake. Having no Host header is not worse than having a bogus Host
header. The Host header was a hack anyway because the request URI
wasn't absolute. We don't have to keep that hack for WebSocket.

I'm voting for CONNECT method with real Host header.

= Inconsistent data regarding cache poisoning attack =

Although the Upgrade handshake reduced firewall circumvention attack
to 1/1000, it does not have the same luck with cache poisoning attack,
according to the paper. 50% attacks still got though. That is *very*
surprising. Caching proxies must demarcate requests precisely, how do
they have such a higher tolerance of corrupt stream? How come 99.9%
host-based-routing proxies are busted by the stream, yet 50% of
ip-based caching proxies are not busted? I must respectfully
disbelieve the result for now.

- Zhong Yu
Adam Barth
2010-12-01 17:00:35 UTC
Permalink
Post by Zhong Yu
With Upgrade handshake, only 1 (out of 50K) firewall circumvention
attack was successful. While with POST/Java/Flash, the number is
around 1000. The Upgrade handshake is a huge improvement! But why? I
assume that the random bytes and framing bytes in the -76 handshake
corrupted HTTP streams and busted 99.9% of HTTP parsers.
We're worried about the cache poisoning attacks, not the firewall
circumvention attacks.
Post by Zhong Yu
In the singular successful case, the transparent proxy ignored these
non-http bytes and constructed a http request anyway, at least, it
extracted the "Host" header. For this attack to be really useful, it's
not enough that the bytes are tunneled to target.com. The proxy must
strip non-http bytes and send a compliant http request to target.com.
Or, the proxy forwards all bytes to target.com, and target server
strips non-http bytes and reconstructs the intended http request. Did
one of these two things actually happened in the experiment?
We didn't testing the framing in this experiment, just the handshakes.
The target server was a stock Apache server. That means the proxy
forwarded the request in such a form that stock Apache was willing to
respond to it.
Post by Zhong Yu
Even worse for the attacker, it's highly unlikely that the http
response sent back by target.com will be accepted by the WebSocket
client as valid WebSocket stream. If the attacker cannot read the
response from target.com, this attack is less useful than sending a
simple HTTP request.
The combined odds that this attack works over Upgrade handshake is
extremely small.
Indeed. That's why we're worried about the cache poisoning attack instead.
Post by Zhong Yu
With CONNECT handshake the same transparent proxy did not pass through
the firewall circumvention attack. It is very likely that the proxy
routes by Host for each request. The handshake contains an invalid
Host, the routing failed, the connection was aborted, and the attack
couldn't be carried out. Most likely CONNECT wins over Upgrade on this
single case because of the bogus Host header, not because the proxy
understands CONNECT and gives up parsing the rest of stream.
Altering the semantics of Host is a big deal. Even though it turns out
to be "helpful" in this singular case of the experiment, the price far
more exceeds the benefit.
It should be stressed that the paper contains no empirical evidence
that the bogus Host would be helpful in other threat models.
If Host really is a problem, we should simply remove it from
handshake. Having no Host header is not worse than having a bogus Host
header. The Host header was a hack anyway because the request URI
wasn't absolute. We don't have to keep that hack for WebSocket.
I'm voting for CONNECT method with real Host header.
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
Post by Zhong Yu
= Inconsistent data regarding cache poisoning attack =
Although the Upgrade handshake reduced firewall circumvention attack
to 1/1000, it does not have the same luck with cache poisoning attack,
according to the paper. 50% attacks still got though. That is *very*
surprising. Caching proxies must demarcate requests precisely, how do
they have such a higher tolerance of corrupt stream? How come 99.9%
host-based-routing proxies are busted by the stream, yet 50% of
ip-based caching proxies are not busted? I must respectfully
disbelieve the result for now.
I'm not sure where you got the 50% number from. You're reading the
table incorrectly. Each of the different handshakes (POST, Upgrade,
and CONNECT) are different experimental conditions (technically
within-subjects conditions). To understand the data in Table II, you
should read the data vertically, not horizontally.

One way to think about the effectiveness of the cache poisoning attack
is in exploits per dollar. We show that (without any targeting) an
attacker can achieve 8 exploits for $100, which is concerning.

Adam
Greg Wilkins
2010-12-01 17:14:50 UTC
Permalink
Post by Adam Barth
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
+1

What concerns there are about CONNECT are probably best evaluated with
working code, test deployments and without the distraction of the
debate about bogus host headers.

cheers
John Tamplin
2010-12-01 17:18:16 UTC
Permalink
Post by Greg Wilkins
Post by Adam Barth
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
+1
What concerns there are about CONNECT are probably best evaluated with
working code, test deployments and without the distraction of the
debate about bogus host headers.
I do have working code for Adam's first proposed handshake at the
websocket-draft-eval project, and it could easily be updated to a more
recent version if anyone wanted to test another implementation against it.
--
John A. Tamplin
Software Engineer (GWT), Google
Willy Tarreau
2010-12-01 18:35:40 UTC
Permalink
Post by Adam Barth
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
I agree that this work should be incremental. The difficulty as we're
working today is that you presented a replacement proposal. It is very
hard to agree on multiple changes at once.

If we want to progress, we should consider replacing just the GET+Upgrade
with a CONNECT and not change anything else (meaning we keep the host and
Hello framess). Only then we can study what else can be done.

Willy
John Tamplin
2010-12-01 18:43:59 UTC
Permalink
Post by Willy Tarreau
Post by Adam Barth
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
I agree that this work should be incremental. The difficulty as we're
working today is that you presented a replacement proposal. It is very
hard to agree on multiple changes at once.
If we want to progress, we should consider replacing just the GET+Upgrade
with a CONNECT and not change anything else (meaning we keep the host and
Hello framess). Only then we can study what else can be done.
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal.  Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.

So, if we really want this to be incremental, it would be a change
from Ian's last draft.

As I understand it, these are the components of Adam's latest proposal:
 1) use CONNECT instead of GET+Upgrade
2) use a fixed, bogus host header and mask the real headers
3) mask all payload data
4) encode the headers as JSON

--
John A. Tamplin
Software Engineer (GWT), Google
Willy Tarreau
2010-12-01 18:48:28 UTC
Permalink
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal.  Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
I'm sorry, I thought we had that in -03. At some point I'm getting lost
between proposals and drafts :-)
Post by John Tamplin
So, if we really want this to be incremental, it would be a change
from Ian's last draft.
That's what I wanted indeed.
Post by John Tamplin
 1) use CONNECT instead of GET+Upgrade
2) use a fixed, bogus host header and mask the real headers
3) mask all payload data
4) encode the headers as JSON
I think we agree on the process then !

Cheers,
Willy
Eric Rescorla
2010-12-01 19:00:05 UTC
Permalink
Post by Willy Tarreau
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal. Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
I'm sorry, I thought we had that in -03. At some point I'm getting lost
between proposals and drafts :-)
Post by John Tamplin
So, if we really want this to be incremental, it would be a change
from Ian's last draft.
That's what I wanted indeed.
Post by John Tamplin
1) use CONNECT instead of GET+Upgrade
2) use a fixed, bogus host header and mask the real headers
3) mask all payload data
I thought that we already agreed on this point weeks ago.

-Ekr
Post by Willy Tarreau
4) encode the headers as JSON
I think we agree on the process then !
Cheers,
Willy
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
Maciej Stachowiak
2010-12-01 21:47:13 UTC
Permalink
Post by Willy Tarreau
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal. Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
I'm sorry, I thought we had that in -03. At some point I'm getting lost
between proposals and drafts :-)
Post by John Tamplin
So, if we really want this to be incremental, it would be a change
from Ian's last draft.
That's what I wanted indeed.
Post by John Tamplin
1) use CONNECT instead of GET+Upgrade
2) use a fixed, bogus host header and mask the real headers
3) mask all payload data
I thought that we already agreed on this point weeks ago.
I think what's new now is that we are approaching consensus on adopting point (1).

It sounds like we don't yet have consensus on (2) - people would rather adopt (1) first, and then examine it further.

I don't recall the state of the discussion on (3). I think the new XOR-masking likely addresses the concerns with the original AES masking.

Regards,
Maciej
Zhong Yu
2010-12-01 22:12:21 UTC
Permalink
If HTTP compliant is important, we cannot arbitrarily separate Method
from headers.

CONNECT with bogus Host is hardly HTTP compliant. A correctly
implemented end point should reject it. It's a flaw if it's accepted.
Should WebSocket be based on such flaws?

CONNECT with real Host seems to be OK. And Adam's experiments did NOT
reveal any security problems caused by a real Host header in the
handshake.

Does Roy have any problem with CONNECT + real Host being used for
WebSocket tunneling?
Post by Eric Rescorla
Post by Willy Tarreau
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal.  Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
I'm sorry, I thought we had that in -03. At some point I'm getting lost
between proposals and drafts :-)
Post by John Tamplin
So, if we really want this to be incremental, it would be a change
from Ian's last draft.
That's what I wanted indeed.
Post by John Tamplin
 1) use CONNECT instead of GET+Upgrade
 2) use a fixed, bogus host header and mask the real headers
 3) mask all payload data
I thought that we already agreed on this point weeks ago.
I think what's new now is that we are approaching consensus on adopting point (1).
It sounds like we don't yet have consensus on (2) - people would rather
adopt (1) first, and then examine it further.
I don't recall the state of the discussion on (3). I think the new
XOR-masking likely addresses the concerns with the original AES masking.
Regards,
Maciej
Greg Wilkins
2010-12-01 19:01:19 UTC
Permalink
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal.  Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
As proposed, the Hello frames do not cost an extra round trip.


The Hello frames are proposed to replace the current unframed bytes.
There primary purpose is to test the connection after an upgrade to
see if WS frames really can be exchanged. The secondary purpose was
to carry nonces and hashes.

I think with CONNECT there is probably less need for such Hello
packets, as I think it much more likely that if a CONNECT succeeds
then the path will be good. But there could still be some failure
cases, so there may still be value. For example, consider a really
dumb intermediary that reads a HTTP request in full, then forwards it
and then reads the response in full. Such an intermediary would be
able to forward a CONNECT and the 200 response, but would not then
function as a WS intermediary. Sending the Hello frame from the
server would detect this as the client would timeout waiting for it.
Without the Hello frame, the client would never know if the connection
is working or if the server just has nothing to say.

So this is why I think we should have kept incrementally improving the
current handshake, so we could now simply switch to CONNECT. But we
still have the issue of the unframed bytes and the space encoded
nonces etc. I think both of these things need to go regardless of
a switch to CONNECT. Thus I think we should accept the Hello
proposals before switching to CONNECT (but I don't necessarily think
we need a draft inbetween).

regards
Post by John Tamplin
So, if we really want this to be incremental, it would be a change
from Ian's last draft.
 1) use CONNECT instead of GET+Upgrade
 2) use a fixed, bogus host header and mask the real headers
 3) mask all payload data
 4) encode the headers as JSON
--
John A. Tamplin
Software Engineer (GWT), Google
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi
John Tamplin
2010-12-01 19:10:58 UTC
Permalink
Post by Greg Wilkins
As proposed, the Hello frames do not cost an extra round trip.
Unless I misunderstood your proposal, doesn't the server have to wait
for the client's Hello reply before it can send any messages? That
seems like it adds one RTT (not two, as it would be if the first Hello
wasn't piggy-backed with the server response).
Post by Greg Wilkins
The Hello frames are proposed to replace the current unframed bytes.
There primary purpose is  to test the connection after an upgrade to
see if WS frames really can be exchanged.  The secondary purpose was
to carry nonces and hashes.
I think with CONNECT there is probably less need for such Hello
packets, as I think it much more likely that if a CONNECT succeeds
then the path will be good.   But there could still be some failure
cases, so there may still be value.   For example, consider a  really
dumb intermediary that reads a HTTP request in full, then forwards it
and then reads the response in full.  Such an intermediary would be
able to forward a CONNECT and the 200 response, but would not then
function as a WS intermediary.  Sending the Hello frame from the
server would detect this as the client would timeout waiting for it.
Without the Hello frame, the client would never know if the connection
is working or if the server just has nothing to say.
I agree the Hello frames are useful in this case. However, how often
is this case present, and is getting a WebSocket-layer timeout rather
than app-layer (which in most cases will have to be present anyway)
worth the price for all the other cases? I don't have any numbers for
it (do you?), but my gut feeling is it is low.
Post by Greg Wilkins
So this is why I think we should have kept incrementally improving the
current handshake, so we could now simply switch to CONNECT.  But we
still have the issue of the unframed bytes and the space encoded
nonces etc.     I think both of these things need to go regardless of
a switch to CONNECT.    Thus I think we should accept the Hello
proposals before switching to CONNECT (but I don't necessarily think
we need a draft inbetween).
Except that depending on what we switch to, those things you want
removed aren't present at all, such as in Adam's proposals. So,
moving them somewhere else doesn't seem like an incremental step but
rather wasted effort.
--
John A. Tamplin
Software Engineer (GWT), Google
Greg Wilkins
2010-12-01 19:40:55 UTC
Permalink
Post by John Tamplin
Post by Greg Wilkins
As proposed, the Hello frames do not cost an extra round trip.
Unless I misunderstood your proposal, doesn't the server have to wait
for the client's Hello reply before it can send any messages?  That
seems like it adds one RTT (not two, as it would be if the first Hello
wasn't piggy-backed with the server response).'
The server can send messages as soon as it has sent it's Hello.
Post by John Tamplin
I agree the Hello frames are useful in this case.  However, how often
is this case present, and is getting a WebSocket-layer timeout rather
than app-layer (which in most cases will have to be present anyway)
worth the price for all the other cases?  I don't have any numbers for
it (do you?), but my gut feeling is it is low.
I agree that Hellos may be less useful with CONNECT. But we have to
do something about the current handshakes unframed bytes and space
encoded nonces. If we leave the unframed bytes as they are with
CONNECT, then we will probably still have the identified issue of an
intermediary that does not forward the bytes and the server hanging
while it tries to read them.
Post by John Tamplin
Except that depending on what we switch to, those things you want
removed aren't present at all, such as in Adam's proposals.
Adam's complete proposal has other aspects to it that are not as well
accepted as trying CONNECT.

If we do agree that CONNECT is better than Upgrade, that is not a
reason to completely adopt the first proposal that uses CONNECT
without questioning each of it's elements.

The handshake is in such a mess because we accepted a big bundle of
changes after only agreeing one aspect of them. We have now spent
months talking about the removal of the additional "features" that
crept in with that batch.
Post by John Tamplin
 So, moving them somewhere else doesn't seem like an incremental step but
rather wasted effort.
Incremental changes are always wasted effort if you are 100% sure you
know all the increments in advance.
The whole point of incremental changes is that you can re-evaluate
along the way and perhaps revert some changes made earlier when
considered in the light of subsequent changes.
Maciej Stachowiak
2010-12-01 21:51:49 UTC
Permalink
Post by Greg Wilkins
Post by John Tamplin
I agree the Hello frames are useful in this case. However, how often
is this case present, and is getting a WebSocket-layer timeout rather
than app-layer (which in most cases will have to be present anyway)
worth the price for all the other cases? I don't have any numbers for
it (do you?), but my gut feeling is it is low.
I agree that Hellos may be less useful with CONNECT. But we have to
do something about the current handshakes unframed bytes and space
encoded nonces. If we leave the unframed bytes as they are with
CONNECT, then we will probably still have the identified issue of an
intermediary that does not forward the bytes and the server hanging
while it tries to read them.
There is a reasonable subset of Adam & Eric's proposal that includes CONNECT, but omits the bogus host header, JSON headers and payload masking. It would not have unframed bytes or space encoded nonces.

I think that would be a decent starting point, after which we could evaluate the remaining aspects.

Regards,
Maciej
John Tamplin
2010-12-01 22:05:47 UTC
Permalink
Post by Maciej Stachowiak
There is a reasonable subset of Adam & Eric's proposal that includes
CONNECT, but omits the bogus host header, JSON headers and payload masking.
It would not have unframed bytes or space encoded nonces.
I think that would be a decent starting point, after which we could evaluate
the remaining aspects.
Ok, so if we took this approach, the proposed draft changes would be to include:
- using CONNECT instead of GET+Upgrade
- uses the real host/port in the CONNECT and Host header
- all handshake headers would be normal headers in the HTTP request/response
- keys would be included in headers not unframed bytes, with no space encoding
- no masking of headers or payload would take place
- no Hello frames

Is that correct?

If so, then I agree that would be a good step to see if we can get
consensus on the less controversial parts before moving on to areas
where there is more disagreement.
--
John A. Tamplin
Software Engineer (GWT), Google
Greg Wilkins
2010-12-02 05:25:25 UTC
Permalink
 - using CONNECT instead of GET+Upgrade
+1 (give it a go at least and see if we can make it not look like an
abomination to those with HTTP eyes).
 - uses the real host/port in the CONNECT and Host header
To be clear - that would be something like

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

and not the proposal I made to use a dedicated port (which can be
consider later)
 - all handshake headers would be normal headers in the HTTP request/response
 - keys would be included in headers not unframed bytes, with no space encoding
Since the current draft contains only a client nonce and server hash,
I think we should start with the same. We can then consider if a
server nonce is needed or if neither are.
 - no masking of headers or payload would take place
 - no Hello frames
Is that correct?
It is a good start
If so, then I agree that would be a good step to see if we can get
consensus on the less controversial parts before moving on to areas
where there is more disagreement.
... where there is more agreement yet to be had.

cheers
Greg Wilkins
2010-12-02 05:13:01 UTC
Permalink
Post by Maciej Stachowiak
There is a reasonable subset of Adam & Eric's proposal that includes
CONNECT, but omits the bogus host header, JSON headers and payload masking.
It would not have unframed bytes or space encoded nonces.
+1
Post by Maciej Stachowiak
I think that would be a decent starting point, after which we could evaluate
the remaining aspects.
Good call!
Zhong Yu
2010-12-01 19:57:09 UTC
Permalink
The Hello frame exchange can be initiated by the client.

client to server
HTTP handshake
HELLO

server to client
HTTP handshake
HELLO

In most cased this is done in 1 round trip. Some current
intermediaries may withhold the client HELLO until server HTTP
handshake is received. That's all right, it's a minor performance that
will disappear in long term.

The advantage of using WS frame to test the connection is also
short-term. In the long run, that perspective becomes moot.

It is more useful to move majority of handshake data into WS frames,
keeping HTTP handshake short and simple, thereby reducing WS's
dependency on HTTP syntax. We have more design freedom if we are not
subject to HTTP baggage.
Post by Greg Wilkins
Post by John Tamplin
AFAIK, the Hello frames do not appear in any draft and only in Greg's
proposal.  Personally, I am not sure what exactly they buy us and I
don't know if we want to pay the extra round trip for them.
As proposed, the Hello frames do not cost an extra round trip.
Zhong Yu
2010-12-01 19:45:01 UTC
Permalink
Post by Adam Barth
Post by Zhong Yu
In the singular successful case, the transparent proxy ignored these
non-http bytes and constructed a http request anyway, at least, it
extracted the "Host" header. For this attack to be really useful, it's
not enough that the bytes are tunneled to target.com. The proxy must
strip non-http bytes and send a compliant http request to target.com.
Or, the proxy forwards all bytes to target.com, and target server
strips non-http bytes and reconstructs the intended http request. Did
one of these two things actually happened in the experiment?
We didn't testing the framing in this experiment, just the handshakes.
The attack occurs after handshake, doesn't it? The attack data must be
framed, otherwise how do you explain that in the POST case, the attack
succeeds 1376 times, while in the Upgrade case, it only succeeds 1
time. What's the difference if it's not due to framing?
Post by Adam Barth
 The target server was a stock Apache server.  That means the proxy
forwarded the request in such a form that stock Apache was willing to
respond to it.
Apache will response 400 Bad Request to garbage inputs. That shouldn't
be counted as a successful attack. It is unclear from your paper how
it is counted.
Post by Adam Barth
Post by Zhong Yu
I'm voting for CONNECT method with real Host header.
IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.
How about CONNECT+Upgrade, everybody is happy.
Post by Adam Barth
Post by Zhong Yu
= Inconsistent data regarding cache poisoning attack =
Although the Upgrade handshake reduced firewall circumvention attack
to 1/1000, it does not have the same luck with cache poisoning attack,
according to the paper. 50% attacks still got though. That is *very*
surprising. Caching proxies must demarcate requests precisely, how do
they have such a higher tolerance of corrupt stream? How come 99.9%
host-based-routing proxies are busted by the stream, yet 50% of
ip-based caching proxies are not busted? I must respectfully
disbelieve the result for now.
I'm not sure where you got the 50% number from.  You're reading the
table incorrectly.  Each of the different handshakes (POST, Upgrade,
and CONNECT) are different experimental conditions (technically
within-subjects conditions).  To understand the data in Table II, you
should read the data vertically, not horizontally.
We can still cross examine the data and find something mysterious.
Maciej Stachowiak
2010-12-01 23:08:48 UTC
Permalink
Post by Zhong Yu
We can still cross examine the data and find something mysterious.
Adam Barth
2010-12-04 09:25:42 UTC
Permalink
Post by Zhong Yu
We can still cross examine the data and find something mysterious.
Zhong Yu
2010-12-03 08:27:19 UTC
Permalink
Adam, is there any chance that the POST experiment poisoned a cache
first, then the Upgrade experiment, which is carried out immediately
afterward, fetched the same poisoned cached result from proxy, and
counted it as a success attack in the Upgrade experiment?

- Zhong Yu
Adam Barth
2010-12-04 09:11:26 UTC
Permalink
Post by Zhong Yu
Adam, is there any chance that the POST experiment poisoned a cache
first, then the Upgrade experiment, which is carried out immediately
afterward, fetched the same poisoned cached result from proxy, and
counted it as a success attack in the Upgrade experiment?
Nope. We controlled for this possibility by using different URLs.

Adam
Bjoern Hoehrmann
2010-12-04 00:26:43 UTC
Permalink
Post by Adam Barth
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
http://www.adambarth.com/experimental/websocket.pdf
It would have been helpful if the key metrics had been summarized in a
simple tabular form for easy comparison (so one would not have to com-
pare an absolute X with a relative "all but two"), but from my cursory
reading this does not seem helpful in deciding which handshake is best.

For instance, the success rate of cache poisoning is not helpful as
they apparently compare as 8 vs 0 of about 50 000 attempts. That could
be chance, that could be a result due to the rich media banner that
may not be supported in certain corporate or mobile settings, it could
be due to mistakes in the experiment, and so on. If tomorrow someone
says they repeated the experiment and got 6 vs 3 I would find that en-
tirely plausible, and if then someone comes along saying it's 3 vs 6
for them, I would find that plausible too, leaving no clear winner.

Could you summarize the key metrics in a tabular form so I can make
sure I haven't missed or misread any of them (between the Upgrade and
the CONNECT handshake primarily)?
--
Björn Höhrmann · mailto:***@hoehrmann.de · 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/
Adam Barth
2010-12-04 09:23:00 UTC
Permalink
Post by Bjoern Hoehrmann
Post by Adam Barth
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
http://www.adambarth.com/experimental/websocket.pdf
It would have been helpful if the key metrics had been summarized in a
simple tabular form for easy comparison (so one would not have to com-
pare an absolute X with a relative "all but two"), but from my cursory
reading this does not seem helpful in deciding which handshake is best.
For instance, the success rate of cache poisoning is not helpful as
they apparently compare as 8 vs 0 of about 50 000 attempts. That could
be chance,
We didn't report the p-value for these observations in the paper, but
running a quick chi-square puts the p-value of these observations
being the same distribution around 0.0047, which is certainly
statistically significant.
Post by Bjoern Hoehrmann
that could be a result due to the rich media banner that
may not be supported in certain corporate or mobile settings, it could
be due to mistakes in the experiment, and so on.
As with any experiment, there are factors we can't control. However,
we do the best we can, and science moves forward.
Post by Bjoern Hoehrmann
If tomorrow someone
says they repeated the experiment and got 6 vs 3 I would find that en-
tirely plausible, and if then someone comes along saying it's 3 vs 6
for them, I would find that plausible too, leaving no clear winner.
I would be surprised if someone made those observations, purely on
mathematical grounds. Another thing that's not reported in the paper
is that we did a series of pilot studies to work out the bugs in our
experiment. Our observations were fairly stable across all these
iterations of the experiment. Of course, reasoning statistically
about the pilot study is tricky due to post-hoc issues, which is why
we only report the final data in the paper, which we can confidently
analyze pre-hoc.
Post by Bjoern Hoehrmann
Could you summarize the key metrics in a tabular form so I can make
sure I haven't missed or misread any of them (between the Upgrade and
the CONNECT handshake primarily)?
Sure. We show that for $100, an attacker is able to succeed in
mounting 8 cache poisoning attacks against the Upgrade handshake.
Note that this value is somewhat of a lower bound because our attacks
are completely untargeted. By targeting the attack, an attacker can
likely be even more cost-efficient. By contrast, we never observed a
single successful cache poisoning attack against the CONNECT handshake
despite 54,534 attempts.

Adam
Continue reading on narkive:
Loading...