[HTTPS-Everywhere] Workarounds for cert CN mismatch, self-signed certs and other brokeness

[Peter Eckersley]

On Sat, Apr 28, 2012 at 06:04:52PM +0200, Ondrej Mikle wrote:
 
> ## Options that could work (more or less):
> 
> 1. FF/Chrome Addon for each service that installs the cert exception and
> necessary HTTPS Everywhere rules (like mine quick-hack "solution")
> 
> 2. Same as 1., but as a part of HTTPS Everywhere (i.e. enable rules disable due
> to PKIX validation if the uses agrees)

I like this idea, merged with some of your Cert Patrol suggestions below.  

The reddit ruleset should be able to contain an alias saying something like:
<trust_alternative_cert for="www.reddit.com" alt="a248.e.akamai.net">

There are probably a lot of places where ruleset authors could manually tell
the browser to trust a specific CDN's cert, or a specific cert for a different
subdomain, in order to HTTPSify things that are currently stuck in HTTP.  We
could make this /only/ happen if the browser was going to send the request
over HTTP anyway, so there is no new security risk.  We should do it.  We're
blocking on several bugs, though:

https://bugzilla.mozilla.org/show_bug.cgi?id=644640
https://code.google.com/p/chromium/issues/detail?id=49469

In the case of the Mozilla bug, I share much of the blame, because I have work
to do to get that moving forward.

> 
> 3. A "generator" of addons that that certs and rules as input, produces specific
> instances of addon 1 for site X.Y.Z.
> 
> Obvious problems with 1., 2. and 3.:
> 
> a) If server cert changes, users will get warnings until dev fixes it. Planned
> cert rotation can be accounted for, but it's different if the cert is changed
> unexpectedly
> 
> b) Either many addon maintainers are needed or it could result in a big burden
> for existing maintainers
> 
> Issues a) and b) can be alleviated via Perspectives/Convergence-like approach,
> thus both maintainer and user can be notified. User can be shown that the cert
> was changed, but network perspective thinks it's ok, and maintainer is notified
> about the necessary update (few days ahead if the cert rollover is planned).
> 
> 
> ## Further options:
> 
> 4. Update/fork Certificate Patrol to have these features:
> 
> i. multiple certificates can be marked as valid, instead of just one (for CDN
> services like google; check on CA name is not exactly secure)
> ii. ability to add certificate override (pin "untrusted" cert)
> iii. pinning possible on both full cert and SubjectPublicKeyInfo
> iv. possibly: consult Perspectives/Convergence on cert change or untrusted cert
> v. later: fetch DANE TLSA records, include them in checking pins
> vi. eventually: more pinning types available e.g. restrictive pin of "valid"
> end-entity/CA cert and "permissive" pins for things like CAcert.org and
> self-signed certs
> vii. maybe: submitting pins by contributors/site owners (not scalable, unless we
> can drag them from Sovereign Keys or Certificate Transparency DBs)
> 
> Features i. and ii. should be quite simple. DANE will require binary NPAPI
> plugin (libunbound is necessary; but that can wait 5 years until it becomes
> somewhat spread in the wild)
> 
> 
> ## Getting full certs
> 
> Perspectives/Convergence won't give you full certs, just the fingerprint or
> confirm "it's ok". Should be ok for most cases (sample exception: MitM case
> where we might want to see full cert seen from "outside"). In case it isn't,
> here is a fork of Perspectives that has two additional methods, get_certs and
> refresh_scan:
> 
> https://github.com/hiviah/perspectives-observatory
> 
> A sample server running the code (feeble VPS, please don't overload; see Notes
> at the end of gihub repo's README on HTTP return codes):
> 
> http://notary1.constructibleuniverse.net:8080/get_certs?host=encrypted.google.com&port=443
> (get EE certs for service)
> http://notary1.constructibleuniverse.net:8080/refresh_scan?host=encrypted.google.com&port=443
> (do immediate refresh
> 
> 
> ## Conclusion
> 
> I like foremost the Certificate Patrol clone usable for cert-pinning. Maybe the
> addon could later "consult with" HTTPS Everywhere so that HTTPS Everywhere rules
> disabled due to bad CN can be enabled automagically.
> 
> Ondrej
> 
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993