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

Paul Wise pabs3 at bonedaddy.net
Wed Mar 5 00:13:26 PST 2014


On Tue, 2014-03-04 at 22:39 -0800, Yan Zhu wrote:

> We've gotten this suggestion a couple times before. Seth Schoen tells me
> that the HTTPS Finder rules are often buggy or incomplete, so it's
> better if humans look at them first and submit them to us (rather than
> have HTTPS Finder automatically submit everything that it finds).

Yeah, that is why I suggest only submitting domains rather than rules.
When you get new domains submitted by users you can pro-actively check
the ruleset, test the domains from multiple network points and update
the ruleset.

> As discussed previously, it would be great for us to decouple ruleset
> updates from extension updates so that we can ship ruleset updates more
> frequently (extension updates happen about once every two months). I'm
> open to the idea of shipping ruleset updates over HTTPS with certificate
> pinning (i.e., bundling the public key with the HTTPS Everywhere
> package) as soon as they get checked into git, but this would mean that
> ruleset updates are less secure than extension updates (since we sign
> extension updates with an offline private key in addition to serving
> them over HTTPS).

How about signing ruleset updates with the same key? It would mean
bringing that key online more often though I guess. Alternatively you
could have a separate online signing key stored in a hardware token.

> (There's a good argument that ruleset security should be equivalent to
> extension security, since an attacker can submit a ruleset update that
> rewrites the extension update URL to a malicious one!)

I think the code could have a hardcoded URL for ruleset updates that
isn't subject to ruleset rewriting?

-- 
bye,
pabs

http://bonedaddy.net/pabs3/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140305/1ed37eb4/attachment.sig>


More information about the HTTPS-Everywhere mailing list