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

Red redwire at riseup.net
Fri Jun 13 08:36:51 PDT 2014


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).
>> 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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140613/5d39f58d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140613/5d39f58d/attachment.sig>


More information about the HTTPS-Everywhere mailing list