I didn't notice it in detail before, but I thought about it a bit more
now because Jim Roskind talked to me about it today. I find the
following line a bit ambiguous: "Whenever an endpoint sends data on a
session which targets a new domain, it MUST use this flag to reset the
compression state. This avoids all possibility of privacy leakage."
What does this mean for the following sequence of SYN_STREAMs?
1) a.foo.com
2) b.foo.com
3) a.foo.com
4) c.foo.com
Do 2, 3, and 4 all have FLAG_RESET_COMPRESSION set? Or just 2 and 4?
If the former, then I'm worried that we'll have too many
FLAG_RESET_COMPRESSIONs and this will negate lots of the advantage of
the header compression. But given the explanation in "If we use the
same stateful compression for requests destined to different security
origins, it is possible for an attacker to learn about the contents
sent to an origin for which it should not.", it seems to me like the
former is indeed the intended interpretation. What's the intended
interpretation here?
Also, I am a bit confused by section 3.1 that states: "Clients SHOULD
NOT open more than one SPDY session to a given origin".
So, a.foo.com and b.foo.com are 2 different origins and should stay on
2 different SPDY sessions, right ?
This would make the RESET_COMPRESSION not needed, or I am missing something ?
Thanks,
Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Normally speaking, yes. But, let's say they present a wildcard
certificate for *.foo.com and a.foo.com maps to 1.1.1.1 and b.foo.com
also maps to 1.1.1.1. Then it would be reasonable to reuse the
authenticated SPDY session that was originally connected for a.foo.com
for b.foo.com too. Chrome does this already.
Completely agreed.
>
> If we posit that the security issue is significant, then I'm concerned
> about the loss of compression that we'd see when we shared a
> connection between multiple hosts.
>
> PLAUSIBLE ALTERNATIVES
>
> If we can't agree the security issue is insignificant (and reuse a
> compression context), it would seem more than reasonable to have
> distinct compression contexts, one per domain within a connection.
> That would certainly provide equivalent security isolation (and
> probably better compression, since cookies for each site would be
> distinct).
Let's agree the security issue is insignificant since it requires
compromising SSL.
I chatted with Adam Langley yesterday and neither of us understand the
motivation behind this. I think we should remove this change.
Under this scenario, an attacker who is able to determine how much his
request got compressed to a.foo.com can learn things about requests to
the other hosts (i.e. cookies). It's a bit tricky to conceive of a way
for the attacker to determine how much of his request was compressed,
since the SPDY reverse proxy has already decompressed it by the time
a.foo.com receives it. It's possible there's a timing channel that
could reveal this information.
It's not clear to me how concerned to be about this scenario. If it's
truly an issue, then I would rather see us use per-origin compression
contexts, rather than FLAG_RESET_COMPRESSION.
On Tue, Aug 16, 2011 at 01:24, William Chan (陈智昌) <will...@chromium.org> wrote:
> It's not clear to me how concerned to be about this scenario. If it's
> truly an issue, then I would rather see us use per-origin compression
> contexts, rather than FLAG_RESET_COMPRESSION.
So, would not this be the same of a session per origin and a
compression context per session ?
Is it so much a problem to open one session per origin, compared to
reuse the same session for different origins, but complicate other
parts such as compression contexts ?
I feel it'll be much simpler to just reinforce one session per origin
like the spec suggests.
But perhaps there are gains I do not see ?
Simon
--
See SPDY draft 3 spec section 1 for reasons to reduce the number of connections.
On Tue, Aug 16, 2011 at 03:09, William Chan (陈智昌) <will...@chromium.org> wrote:
> On Mon, Aug 15, 2011 at 4:58 PM, Simone Bordet <sbo...@intalio.com> wrote:
>> Hi,
>>
>> On Tue, Aug 16, 2011 at 01:24, William Chan (陈智昌) <will...@chromium.org> wrote:
>>> It's not clear to me how concerned to be about this scenario. If it's
>>> truly an issue, then I would rather see us use per-origin compression
>>> contexts, rather than FLAG_RESET_COMPRESSION.
>>
>> So, would not this be the same of a session per origin and a
>> compression context per session ?
>> Is it so much a problem to open one session per origin, compared to
>> reuse the same session for different origins, but complicate other
>> parts such as compression contexts ?
>> I feel it'll be much simpler to just reinforce one session per origin
>> like the spec suggests.
>> But perhaps there are gains I do not see ?
>
> See SPDY draft 3 spec section 1 for reasons to reduce the number of connections.
I had interpreted that as reducing the number of connections per
origin, even if the wording in the spec is "per server".
While I can see the benefits of a single connection per origin, I was
wondering if it was not pushed too much.
Thanks,
This is both perfectly reasonable and completely silly. It's
reasonable because it works, but silly because it works even when only
a single origin is in play and is an old (although unaddressed) issue
with compressing data from mixed sources.
Here's the (old, standard) attack:
The attacker is running script in evil.com. Concurrently, the same
client has a compressed connection open to victim.com and is logged
in, with a secret cookie. evil.com can induce requests to victim.com
by, say, adding <img> tags with a src pointing to victim.com. (The
compressed connection can either be SPDY or TLS+zlib.)
Each of those requests has a secret part (the cookie), a public part
(the browser's typical headers) and an attacker controlled part (the
URL). The problem is that compression ties all those parts together.
The attacker can watch the wire and measure the size of the requests
that are sent. By altering the URL, the attacker could attempt to
minimise the request size: i.e. when the URL matches the cookie.
I've just tried this with an HTTP request for fun and it's pretty easy
to get the first 5 characters in a base64 encoded cookie. The problems
are that the Huffman encoding makes 'e' very short and you have to be
careful not to compress against yourself (i.e. a URL of xyxyxy...).
With a good model of zlib, I think you could extract a ~40 byte cookie
with ~13K requests. That's a practical attack and would make a great
paper if someone has the time.
However, we've never tried to defeat traffic analysis in HTTPS or
SPDY. Maybe cookie extraction is a more interesting result than
telling what page you're reading and so we should try harder?
One option is to compress attacker controlled data with a different
context. Certainly the URL is attacker controlled. In the case of a
shared connection, headers from other requests may be attacker
controlled too although I'm much less worried about this (to the point
where I don't believe it's worth any complexity). We have to be
careful not to increase the memory overhead if we do this.
Another is to pad to a standard granularity. I don't believe that will
actually be effective. An attacker will be able to get right up to
padding boundary and still get a single bit of data out.
We can pad randomly, (preferably inside the compression). This doesn't
stop the attack, but it slows it down to an arbitrary amount.
Cheers
AGL
commit: https://github.com/willchan/SPDY-Specification/commit/cd2f05d34861836d8d0a2dd46d21b8919688e95e
updated spec: http://willchan.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml
I'll push this commit to Mike's repo tomorrow.
More like 6 connections for modern browsers
(http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/)
IIUC, since zlib uses a fixed size sliding window for the compression
context, resetting the compression context doesn't reduce the memory
footprint. I don't think a reset compression context frame is useful.
See http://www.gzip.org/zlib/zlib_tech.html for a discussion of memory
use wrt zlib.
>
> -thanks, Kumar.a
On Thu, Aug 11, 2011 at 5:13 PM, Jim Roskind <j...@google.com> wrote:Completely agreed.
> I didn't think the current draft was ambiguous. I think (in your
> example) that it calls for sending the FLAG_RESET_COMPRESSION with the
> headers for 2, 3, and 4. If there were any other interpretation, then
> the motivation to avoid "privacy leakage" by sending any RESET flags
> would not be satisfied.
>
> I'm not really that convinced of the security issue. I'm guessing
> there is a timing attack that is vaguely plausible, but as noted on
> another thread by Adam Langley, SPDY had already put a lot of trust
> into allowing both streams to reach a singular server on one
> connection.
Ok, I chatted with Adam Barth to understand his privacy leakage
concerns. The conceived scenario is one where we use IP connection
pooling to have a reverse proxy server that serves both a.foo.com and
b.foo.com and both a.foo.com and b.foo.com resolve to the same IP
address and present certs for *.foo.com.
Under this scenario, an attacker who is able to determine how much his
request got compressed to a.foo.com can learn things about requests to
the other hosts (i.e. cookies). It's a bit tricky to conceive of a way
for the attacker to determine how much of his request was compressed,
since the SPDY reverse proxy has already decompressed it by the time
a.foo.com receives it. It's possible there's a timing channel that
could reveal this information.
It's not clear to me how concerned to be about this scenario. If it's
truly an issue, then I would rather see us use per-origin compression
contexts, rather than FLAG_RESET_COMPRESSION.