SDCH and SPDY

[John Lenz]

SPDY is equivalent to using HTTPS.  And this specification call out that the shared dictionary can not be used with HTTPS:

http://www.blogs.zeenor.com/wp-content/uploads/2011/01/Shared_Dictionary_Compression_over_HTTP.pdf

Is it correct then that the two can not be used together?

[Ma Chi]

Quote :"This proposal does not take into account HTTPS. Downloading dictionaries over HTTPS or
advertising dictionaries over HTTPS might introduce new security risks."

The word used is "might". IMHO,What it means is that they had not spend enough time in ensuring that SDCH does not break the https security.

Maybe we can download dictionaries via https?

--
You received this message because you are subscribed to the Google Groups "SDCH" group.
To view this discussion on the web visit https://groups.google.com/d/msg/SDCH/-/fEpN0ao4XrMJ.
To post to this group, send email to SD...@googlegroups.com.
To unsubscribe from this group, send email to SDCH+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/SDCH?hl=en.

--
Best Regards

[John Lenz]

It specifically rules out using HTTPS in these steps:

Given these definitions of domain-match and path-match, a request URL falls within a

dictionary's scope exactly when all of the following are true:

  1. The request URL's host name domain-matches the Domain attribute of the

dictionary.

  2. If the dictionary has a Port attribute, the request port is one of the ports listed in

the Port attribute.

  3. The request URL path-matches the path attribute of the dictionary.

  4. The request is not an HTTPS request

So an implementation can not conform to the spec and allow it over HTTPS.  Have there been any updates?

[Jim R]

In general, SDCH cannot, as you noted in the proposed spec, be used
for HTTPS requests and responses.  The potential attacks that are most
plausible involve replacing a dictionary with a malicious dictionary.
 The protection against such "mistaken" dictionaries in SDCH is not
that strong (at best, it is a strong as about half of a current
cryptograhic hash).

SPDY includes tunneling of some communications such as HTTP, via an
"alternate port and protocol."  SPDY protects its transport channel
from intermediaries, which would be surprised and/or confused this
this "new fangled protocol," by using SSL.  There is no "problem" with
HTTP transaction, including content-encoding of SDCH, being carried
across a SPDY channel.  SSL won't "hurt" SDCH.  The issue is just that
the promises provided by SSL (tamper resistance?) in an HTTPS
transaction are probably less assured if an HTTPS transaction were to
have a content-encoding of SDCH.

Jim

p.s., A secondary concern relates to dictionary generation.  Great
care must be taken in dictionary generation, *IF* it is performed
based on training data that was previously transmitted via SSL.  The
dictionary tends (for most dictionary construction algorithms I've
seen) to incorporate sub-strings of the historic transactions :-/.
 Great care must be taken that there is no "privacy sensitive"
information (Personally Identifiable Info??) recorded into a generated
dictionary.  Keep in mind than any dictionary will generally be
broadly disseminated to many, if not all, users.  This is not a
significant problem when the dictionary was constructed based on
training data that was transmitted (previously) in the clear over
HTTP.

On Mar 1, 8:22 am, John Lenz <concavel...@gmail.com> wrote:
> It specifically rules out using HTTPS in these steps:
>
> Given these definitions of domain-match and path-match, a request URL falls
> within a
> dictionary's scope exactly when all of the following are true:
>   1. The request URL's host name domain-matches the Domain attribute of the
> dictionary.
>   2. If the dictionary has a Port attribute, the request port is one of the
> ports listed in
> the Port attribute.
>   3. The request URL path-matches the path attribute of the dictionary.

> *  4. The request is not an HTTPS request*

>
> So an implementation can not conform to the spec and allow it over HTTPS.
>  Have there been any updates?
>
>
>
>
>
>
>
> On Thu, Mar 1, 2012 at 1:55 AM, Ma Chi <helloma...@gmail.com> wrote:
> > Quote :"This proposal does not take into account HTTPS. Downloading
> > dictionaries over HTTPS or
> > advertising dictionaries over HTTPS might introduce new security risks."
>
> > The word used is "might". IMHO,What it means is that they had not spend
> > enough time in ensuring that SDCH does not break the https security.
>
> > Maybe we can download dictionaries via https?
>

> > On Thu, Mar 1, 2012 at 2:49 PM, John Lenz <concavel...@gmail.com> wrote:
>
> >> SPDY is equivalent to using HTTPS.  And this specification call out that
> >> the shared dictionary can not be used with HTTPS:
>

> >>http://www.blogs.zeenor.com/wp-content/uploads/2011/01/Shared_Diction...

[Visual Zhang]

Try this:enter a Google website like Google Keep,open chromium developer tools,switch to network tab,right click on one item,choose "copy as curl"

You'll get something like this

"curl "https://clients6.google.com/notes/v1/users/me?alt=json&key=AIzaSyCefCLRgSwBqyIdoDJCjMaBtCZgmPx66iU" -H ":host: clients6.google.com" -H ":version: HTTP/1.1" -H "dnt: 1" -H "accept-encoding: gzip,deflate,sdch" -H "x-origin: https://drive.google.com" -H "accept-language: en-US,en;q=0.8" -H "authorization: SAPISIDHASH 

...blablabla"

open chrome://net-internals/#spdy ,you can find there's clients6.google.com spdy sessions.

Just some random guess