[HTTPS-E Rulesets] Pull request for 4 new/updated rules; and an idea for coping with bad certificate CN/untrusted CAs/self-signed certs

Ondrej Mikle ondrej.mikle at gmail.com
Sat Apr 28 07:52:02 PDT 2012


Hi,

I've added and update rules:

* CZ.NIC (CZ TLD domain registry)
* brmlab.cz hackerspace
* abclinuxu.cz rules update (secure cookie + comments)
* reddit.com rules update (part is disabled due to www.reddit.com invalid CN in
cert; making/testing rules for reddit is akin to getting proof to
four-color-theorem right)

Git repo branch is here (branch omikle_rules_001, I made the branch from master
HEAD, wasn't sure whether that's the right point to branch it off):

https://github.com/hiviah/https-everywhere/tree/omikle_rules_001


One question towards secure cookies:
The reddit.com rule needs to define <target host=".reddit.com">, otherwise some
of the cookies won't be switched to secure. Though I haven't seen anything like
that in any other rule. Some weird anomaly?
(BTW Web Developer is very handy tool for checking whether the cookie rules
work, in case someone is looking for one.)

Also, props on your rule validity/relax-ng checking code, it's awesome.


The idea for dealing with CN mismatches, CAcert.org, self-signed certs, etc.:

I've been using custom reddit HTTPS Everywhere rules for 1+ year (updating it
here and there), but it's apparently too hard for common users to add the one
cert exception for CN mismatch.

The "fix" idea is dumb-simple (basically a cert-pin): I created an addon that
just adds the exception
(https://constructibleuniverse.net/reddit-ssl/reddit-ssl.xpi). Is there a better
way for a foreign addon to install custom HTTPS Everywhere rules than to simply
create them in the HTTPSEverywhereUserRules directory?

The approach could work for other "big" sites as a part of HTTPS Everywhere,
obviously it adds another burden to maintain. It'll throw warnings if server
cert changes before devs can update the addon and push the update, for instance.

I'll post details in a while to https-everywhere list with alternative
solutions, it seems to be more appropriate place.

Ondrej




More information about the HTTPS-Everywhere-Rules mailing list