On 03/05/2014 01:13 AM, Dave Warren wrote: > Perhaps it would be wise to have the extension refuse to re-write any > URL involved with the update mechanism (or at least require any rule > that does to be signed using the offline key), along with the use of > certificate pinning to validate the SSL channel used for ruleset updates. > > It might not be perfect, but if the extension calls a known URL, it > shouldn't be too difficult to simply ignore any rule that attempts to > apply to the domain(s) involved with the ruleset update process. >
Interesting suggestion! However, I take back my original assertion that an attacker can hijack HTTPS Everywhere updates by rewriting the update URL; this won't work because we include a signed hash of the updated file in our update manifest (https://www.eff.org/files/https-everywhere-update-2048.rdf), which must verify before Firefox accepts the update. Phew. But given that Mozilla doesn't require hashes or signing keys for extension updates over HTTPS, other extensions that a user has installed may be vulnerable to hijacking via a malicious ruleset, which is just as bad. (I'm not even sure if addons.mozilla.org signs all addon update hashes or just relies on HTTPS + human moderator review.) So I don't think it's feasible to maintain a hard-coded list of every URL pattern that should never be rewritten, but if we're willing to relax the requirement that all ruleset updates be signed with EFF's offline key, there might be an acceptable way to ship ruleset updates almost as soon as they're checked into git. Here's my proposal: 1. Have a https-everywhere-rules repository at git.torproject.org that contains all the XML ruleset files and a update-rules.rdf file that includes the URL, version number, and hash of the latest revision of default.rulesets.zip (zip file containing the minified XML rulesets). 2. Include two signatures on update-rules.rdf, one from a key owned by the primary maintainer of HTTPS Everywhere (me at the moment) and one from any of the other people with push access to the repository (Peter, Mike Perry, etc.). These keys should be kept offline when not in use (on smartcards or USB sticks). 3. Include some code in HTTPS Everywhere that periodically (once per day?) checks update-rules.rdf for a higher version number. If one is found and the signature on update-rules.rdf verifies, the client downloads the new rulesets library, verifies the hash, and installs the new rulesets library. The update signing keys are included in HTTPS Everywhere. 4. If any of the update signing keys are compromised or lost, we make an HTTPS Everywhere release with replacement keys ASAP and also post a revocation statement signed with the main HTTPS Everywhere signing key inside update-rules.rdf. (This is necessary because many clients will check update-rules.rdf before they check the HTTPS Everywhere update.rdf.) If a client sees a valid revocation statement in update-rules.rdf, it unpins the revoked key. We could also block rewrites to the update-rules.rdf URL as an extra security measure. -Yan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
