SDCH over HTTPS
11 views
Skip to first unread message
Chris Bentzel
Jun 25, 2014, 11:19:33 AM6/25/14
to sd...@googlegroups.com
We're interested in adding SDCH-over-HTTPS support to the Chromium
project and Chrome.
The original design document (https://goo.gl/2zGXkU) explicitly
forbade using SDCH for HTTPS resources.
With some amendments, we believe that security concerns about this can
be addressed.
-------------
a) Can attacker-provided dictionaries over HTTP be used to inject
content into HTTPS-provided responses? Even without amendments this
may not be a feasible attack since SDCH identifies dictionaries using
48 bits of the SHA-2 hash of the contents, rather than a URL. However,
there is still a risk, so the design document should change to specify
that HTTPS URLs only fall within scope of HTTPS-retrieved
dictionaries.
b) Can passive attackers determine user behavior over HTTPS by
observing dictionary retrievals and advertisements? It's possible
that dictionaries are highly tied to individual users or specific
URLs.
If an HTTPS response advertises an HTTP URL in the Get-Dictionary
header and the client retrieves it, some information could be
revealed. This behavior is already prevented in the design document,
since Get-Dictionary URLs are required to be same-origin as the
response.
Advertising HTTPS-retrieved dictionaries in an Avail-Dictionary header
for an HTTP request could also reveal information. This should be
addressed by specifying that HTTP URLs only fall within scope of
HTTP-retrieved dictionaries. Combined with the change described in a)
above, this means that there is an implicit scheme associated with
each dictionary based on how it was retrieved, and the scheme of the
URL must match the implicit scheme of the dictionary.
c) Is SDCH-over-HTTPS subject to compression oracle attacks similar to
CRIME/BREACH? One of the main differences between SDCH and those
attacks is that the compression context is not supplied by the
attacker. However, this does not mean that servers are completely
immune to attacks. agl suggested a theoretical possibility where a
server sends a static response XOR'ed with user-provided data. If an
attacker had the contents of a dictionary (which is likely publicly
available), and provided data which reduced the size of the response
when XOR'ed with the static response, the attacker may then be able to
determine the contents of the static response.
Overall it does not seem like this style of attack is practical, but
counter-arguments are extremely welcome as they will make
SDCH-over-HTTPS a bad idea.
------------
Proposed deltas to the design document (these are also inserted as
comments on the design document at https://goo.gl/2zGXkU)
1) In the "Dictionary Scope" section, remove the "The request is not
an HTTPS request" entry from the list. Add "The request URL's scheme
matches the scheme of the dictionary".
2) Remove the "The request is not an HTTPS request." entry from the
"Server Role in HTTP Response Generation" section.
3) In the "User Agent Role in HTTP Response Handling" section, change
the bit about whether the user agent may retrieve a dictionary to
"The user agent may retrieve a dictionary if the origin of the
dictionary matches the origin of the referrer. HTTP redirects may only
be followed if the origin matches as well."
4) Remove the first paragraph of the "Data Integrity" section that
starts with "This proposal does not take into account HTTPS."
5) Add a security concerns section to the document summarizing some of
the issues raised above.
project and Chrome.
The original design document (https://goo.gl/2zGXkU) explicitly
forbade using SDCH for HTTPS resources.
With some amendments, we believe that security concerns about this can
be addressed.
-------------
a) Can attacker-provided dictionaries over HTTP be used to inject
content into HTTPS-provided responses? Even without amendments this
may not be a feasible attack since SDCH identifies dictionaries using
48 bits of the SHA-2 hash of the contents, rather than a URL. However,
there is still a risk, so the design document should change to specify
that HTTPS URLs only fall within scope of HTTPS-retrieved
dictionaries.
b) Can passive attackers determine user behavior over HTTPS by
observing dictionary retrievals and advertisements? It's possible
that dictionaries are highly tied to individual users or specific
URLs.
If an HTTPS response advertises an HTTP URL in the Get-Dictionary
header and the client retrieves it, some information could be
revealed. This behavior is already prevented in the design document,
since Get-Dictionary URLs are required to be same-origin as the
response.
Advertising HTTPS-retrieved dictionaries in an Avail-Dictionary header
for an HTTP request could also reveal information. This should be
addressed by specifying that HTTP URLs only fall within scope of
HTTP-retrieved dictionaries. Combined with the change described in a)
above, this means that there is an implicit scheme associated with
each dictionary based on how it was retrieved, and the scheme of the
URL must match the implicit scheme of the dictionary.
c) Is SDCH-over-HTTPS subject to compression oracle attacks similar to
CRIME/BREACH? One of the main differences between SDCH and those
attacks is that the compression context is not supplied by the
attacker. However, this does not mean that servers are completely
immune to attacks. agl suggested a theoretical possibility where a
server sends a static response XOR'ed with user-provided data. If an
attacker had the contents of a dictionary (which is likely publicly
available), and provided data which reduced the size of the response
when XOR'ed with the static response, the attacker may then be able to
determine the contents of the static response.
Overall it does not seem like this style of attack is practical, but
counter-arguments are extremely welcome as they will make
SDCH-over-HTTPS a bad idea.
------------
Proposed deltas to the design document (these are also inserted as
comments on the design document at https://goo.gl/2zGXkU)
1) In the "Dictionary Scope" section, remove the "The request is not
an HTTPS request" entry from the list. Add "The request URL's scheme
matches the scheme of the dictionary".
2) Remove the "The request is not an HTTPS request." entry from the
"Server Role in HTTP Response Generation" section.
3) In the "User Agent Role in HTTP Response Handling" section, change
the bit about whether the user agent may retrieve a dictionary to
"The user agent may retrieve a dictionary if the origin of the
dictionary matches the origin of the referrer. HTTP redirects may only
be followed if the origin matches as well."
4) Remove the first paragraph of the "Data Integrity" section that
starts with "This proposal does not take into account HTTPS."
5) Add a security concerns section to the document summarizing some of
the issues raised above.
Ben Maurer
Jun 25, 2014, 6:10:57 PM6/25/14
to SD...@googlegroups.com, sd...@googlegroups.com
It seems like (a) and (b) are completely addressed by the modifications to the spec (specifically, limiting SDCH dictionaries for HTTPS requests to HTTPS domains).
If (c) is an issue, implementing sites have the remedy of simply disabling SDCH. Given that it will take a relatively high level of sophistication to implement SDCH, it seems pretty likely that servers implementing SDCH would turn it off quite quickly in the event of an issue.
One concrete way in which (c) could be an issue is if the implementing site uses allow target matches (allowing compression of matches within the target document itself). I did some testing on Facebook pages and found that allow target matches can actually improve compression rate over gzip (because gzip has a 32 KB window for matches it sometimes doesn't find matches further back in the document). Any site using this would have to be careful about the security implications of the setting.
Ben Maurer
Jun 25, 2014, 6:15:50 PM6/25/14
to SD...@googlegroups.com, sd...@googlegroups.com
I actually realized I didn't read this part of the spec:
VCD_TARGET flag and target COPY instructions not allowed for SDCH
The SDCH protocol is intended to produce a delta between static dictionary data and target data. Secondary compression with gzip will be used to eliminate redundancy within the target data. For this reason, when using VCDIFF for SDCH, the Win_Indicator flag should always include the VCD_SOURCE flag, never the VCD_TARGET flag. COPY instructions should only reference addresses within the source data, never within the previously decoded target.Does/Will chrome enforce this rule? As I mentioned in my other email, target matches can actually have a positive effect on compression, even when post-processed with gzip.
On Wednesday, June 25, 2014 8:19:33 AM UTC-7, Chris Bentzel wrote:
Chris Bentzel
Jun 26, 2014, 4:45:19 PM6/26/14
to SD...@googlegroups.com
On Wed, Jun 25, 2014 at 3:10 PM, Ben Maurer <ben.m...@gmail.com> wrote:
> It seems like (a) and (b) are completely addressed by the modifications to
> the spec (specifically, limiting SDCH dictionaries for HTTPS requests to
> HTTPS domains).
Yes
> It seems like (a) and (b) are completely addressed by the modifications to
> the spec (specifically, limiting SDCH dictionaries for HTTPS requests to
> HTTPS domains).
>
> If (c) is an issue, implementing sites have the remedy of simply disabling
> SDCH. Given that it will take a relatively high level of sophistication to
> implement SDCH, it seems pretty likely that servers implementing SDCH would
> turn it off quite quickly in the event of an issue.
it may save some server development time...
> You received this message because you are subscribed to the Google Groups
> "SDCH" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to SDCH+uns...@googlegroups.com.
> To post to this group, send email to SD...@googlegroups.com.
> Visit this group at http://groups.google.com/group/SDCH.
> For more options, visit https://groups.google.com/d/optout.
openvcdiff
Jun 26, 2014, 5:17:38 PM6/26/14
to SD...@googlegroups.com, sd...@googlegroups.com
Hi Ben:
On Wednesday, June 25, 2014 3:15:50 PM UTC-7, Ben Maurer wrote:
I actually realized I didn't read this part of the spec:VCD_TARGET flag and target COPY instructions not allowed for SDCH
The SDCH protocol is intended to produce a delta between static dictionary data and target data. Secondary compression with gzip will be used to eliminate redundancy within the target data. For this reason, when using VCDIFF for SDCH, the Win_Indicator flag should always include the VCD_SOURCE flag, never the VCD_TARGET flag. COPY instructions should only reference addresses within the source data, never within the previously decoded target.Does/Will chrome enforce this rule? As I mentioned in my other email, target matches can actually have a positive effect on compression, even when post-processed with gzip.
Chromium does enforce this rule. Please refer to line 369 of sdch_filter.cc:
There is another motivation for this restriction which is not explicitly mentioned in the document. Using VCD_TARGET would require the decoder to keep the entire target file in memory. Prohibiting VCD_TARGET (and using interleaved mode) allows streaming delta input to be decoded into streaming target output.
Cheers,
Lincoln
Reply all
Reply to author
Forward
0 new messages