On 13 June 2014 04:08, Red <[email protected]> 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). Best regards, Maxim Nazarenko
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
