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

[Ondrej Mikle]

Hi,

this is a followup to
https://mail1.eff.org/pipermail/https-everywhere-rules/2012-April/001109.html .

We are aware that there are all kinds of brokeness in HTTPS that show cert
warnings (transvalid incomplete chains, CN mismatches, unknown CAs, etc).

I've used to view it as "necessary evil", but what changed my mind is that
Reddit won't be switching to "full HTTPS" even after many promises anytime soon,
if ever (cited reason: high cost due to transfer to different Akamai
service/plan). All that user needs to do, is use the rules posted above and add
a single cert exception. Though even for a moderately tech-savvy user that may
be an arcane thing.


## 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)

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