[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates
nz.phone at mail.ru
Fri Jun 13 04:33:14 PDT 2014
On 13 June 2014 04:08, Red <redwire at riseup.net> wrote:
> If we were to serve a separate file containing the signature over the
> raw bytes of the update.json file, wouldn't we also need to provide some
> assurance that the contents of that file haven't been falsified, i.e.,
> have a hash available or something, as well? I might not understand the
> security requirements in this case well enough, but I get the impression
> that this would effectively lead us to an infinite loop of fetching a
> file with some verification data, and then needing a new file to provide
> proof of the validity of that data and so on.
> As I understand our requirements, appending the signature to the first
> line of update.json might work out, since it'll be a signature of the
> content to follow and shouldn't be tamper-able.
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the HTTPS-Everywhere