[HTTPS-Everywhere] ideas for improvements to development and use of the ruleset

[Yan Zhu]

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


-------------- 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/20140305/a36b1e5c/attachment.sig>