[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

Yan Zhu yan at eff.org
Fri Jun 13 10:02:57 PDT 2014


On 06/13/2014 08:36 AM, Red wrote:
> On 2014-06-13, 6:57 AM, Jacob S Hoffman-Andrews wrote:
>>> As far as I understand, there is no difference. I am not a crypo
>>> expert, but here is my understanding of the process:
>>> 1) An active attacker can MITM the connection and falsify ANY data
>>> being sent, unless the server certificate is pinned (which it is not,
>>> by deafult).

FWIW, it will be pinned starting with Firefox 31 or so! :D :D

We can even hack it and add some code in HTTPS Everywhere to pin
EFF.org's certificate earlier, but I'm not sure it's worth the effort.

>>> 2) The signature is verified against EFF public key hardcoded into
>>> the extension. The verification will fail if either the data or the
>>> signature is tampered with (unless the attacker can modify the
>>> hardcoded public key, but then the user is screwed anyway).
>> This is correct. Detached signatures are just as safe.
>>
>> There's one little quirk in that you'd want to deploy a new
>> update.json with a new detached sig simultaneously, otherwise some
>> clients would fetch the old sig with the new update.json

In general, I was thinking something like this for handling signature
verification failures:

1. Report the text of the update.json file (or maybe just the hash?),
the full signature, and the timestamp of the verification attempt to
some eff.org server. We can attempt to send over Tor using the SSL Obs.
proxy detection code and also strip potentially-identifying HTTP
headers. If reporting fails, try again in 5 minutes?

2. Attempt to re-fetch and verify every 5 minutes plus some random
padding for the next hour until verification succeeds.

Normally, the extension would be checking for updates on startup and
every 2(?) hours plus random padding. It only attempts signature
verification if the version number in update.json is greater than the
current version number.

Zack: it would be good to add these details about when to fetch and
attempt sign. verification and what to do in case of sig. verification
failures/other errors to the spec.

> 
> Okay, I think I understand properly now.  I had forgotten that
> signatures are produced using a private key, so can't be so easily faked
> by an attacker.
> So our proposed method for determining the authenticity of the
> update.json file is this:
> Reduce the format down to
> {
> 
> |    "branch"  : <ruleset branch>,
>     "date"    : <the date the new db was released>,
>     "changes" : <a short description of recent changes>,
>     "version" : <ruleset release version>,
>     "hash"    : <the hash of the db file>,
>     "source"  : <the URL serving the updated ruleset db>|
> 
> }
> and then take the signature over the raw bytes in this file.  We write
> the signature we produce to a file update.json.sig and have the
> extension fetch both files, using the contents of update.json.sig to
> verify the contents of update.json in the unparsed form are accurate.
> 
> Is this correct?

As far as I can tell, yes.

> 
> 
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140613/e547bfc1/attachment.sig>


More information about the HTTPS-Everywhere mailing list