[HTTPS-Everywhere] what does HTTPS-Everywhere consider a "valid" X.509 certificate? [was: Re: Custom rules]

https-everywhere at lists.grepular.com https-everywhere at lists.grepular.com
Fri Oct 15 09:03:24 PDT 2010


On 15/10/2010 16:12, Daniel Kahn Gillmor wrote:

>> Is there a policy on "invalid" certificates for this add-on? For
>> example, what about websites that have certificates from cacert.org?
>> Their root isn't installed in any of the major browsers yet... Does that
>> mean they shouldn't be included? Self signed certs? Certs where the CN
>> doesn't match?
> 
> This question has been asked a few times, and the answers i've seen so
> far have been that https-everywhere prefers to avoid redirecting to
> sites that cause security exceptions.
> 
> While i can understand the sentiment behind this goal, it's a bit
> problematic, because:
> 
>  (a) not every browser ships the same default "trusted" root certificate
> authorities, and
> 
>  (b) users have legitimate reasons to want to modify the list of trusted
> roots themselves (e.g. adding authorities they are comfortable with, or
> disabling authorities they do not actually trust)
> 
> FWIW, even self-signed certs and certs where the CN doesn't match are
> acceptable in many reasonable contexts, like browser plugins that let
> the user take a TOFU (trust on first use) approach (e.g. Perspectives or
> Certificate Patrol) or that validate the raw key material out-of-band
> via other mechanisms (e.g. Monkeysphere).
> 
> If https-everywhere is going to pick only sites with "valid"
> certificates, the https authors at some level will need to decide which
> CAs are themselves "valid".
> 
> An obvious choice (since this is a firefox extension) is to just punt on
> the larger political implications of deciding on a canonical "trusted
> authority" list, and accept only sites whose certificates are currently
> verifiable by the latest version of firefox's default "trusted" root CA
> list.
> 
> However, sites change certificates (and keys) over time, and firefox's
> own default "trusted" root CA list changes over time too.  So this is
> something of a moving target.
> 
> And to make matters a bit stickier, some websites covered by the current
> ruleset do *not* validate via Firefox's default "trusted" root CA list,
> but the admins of the sites want them listed anyway.  Is that acceptable?

Perhaps there could be a couple of user configuration options?

Trusted certificates only? (default yes?)
Matching CN only? (default yes?)

A couple of new attributes could be provided at either the rule or
ruleset level depending on the granularity required. Eg:

<ruleset name="Reddit" match-cn="no" trusted="yes">
  <rule from="^http://(www\.)?reddit\.com/" to="https://www.reddit.com/"/>
</ruleset>

If there are several rules inside a ruleset and some use trusted certs,
and some not, then the match-cn and trusted attributes could be used at
that level instead?

-- 
Mike Cardwell - Perl/Java/Web developer, Linux admin, Email admin
Read my tech Blog -              https://secure.grepular.com/
Follow me on Twitter -           http://twitter.com/mickeyc
Hire me - http://cardwellit.com/ http://uk.linkedin.com/in/mikecardwell



More information about the HTTPS-everywhere mailing list