[HTTPS-Everywhere] Distributed Observatory detecting "bad" certificates

Maxim Nazarenko nz.phone at mail.ru
Wed Oct 12 00:02:15 PDT 2011


Good morning,

While googling DANE I found this blog entry:
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html
. Looks like almost like SSL Observatory to me. Is it possible to use
this Google DB somehow?

Best regards,
Maxim Nazarenko

On 12 October 2011 01:31, Ondrej Mikle <ondrej.mikle at nic.cz> wrote:
> Hello,
>
> I'd like to ask about (planned) feature of HTTPS Everywhere described here for
> some time:
>
> https://trac.torproject.org/projects/tor/wiki/doc/HTTPSEverywhere/SSLObservatorySubmission
>
> It mentions that it should be able at some point "lets us warn you about
> insecure connections or attacks on your browser". The DB schema outlined in the
> torproject page contains fields like 'known_bad' or 'bad_cert_id'.
>
> Though I haven't found a mention how the "bad" certificates are supposed to be
> detected. I haven't seen any mention in any document or the mailinglist how it's
> supposed to be implemented.
>
>
> Some of the well-known methods I recollect:
>
> - Perspectives (though doesn't work well with CDN hidden behind single IP)
> - Convergence - similar problem with CDN hosts, solution is "if we ever had seen
> that cert fingerprint for the given host, then it's good; false alarm when not
> known"
> - Certificate Patrol - does some heuristics based on when cert expires, checks
> whether the CA is the same (char-by-char issuer comparison). It will get
> confused in case when some hosts of a CDN have cert issued by different CA
> (recent Facebook test cert signed by Verisign)
> - separating CAs by country they should issue certs for (obviously deciding
> between giants like Verising and GTE Cyber Trust is not of much use). Is there
> any list of browser-trusted CA roots mapping CAs to countries they should issue
> certs for? (I know EFF has list of countries with CAs, but no the actual map)
> - CA/cert pinning - Chrome browser for selected Google services; (and DANE
> perhaps years later)
> - deriving issuing CAs for hosts from history (i.e. writing rulesets)
>
> Note: there are at least hundreds CDN hosts serving different certs from behind
> proxy with same IP/hostname
>
>
> Out of curiosity: how many unique certs have been collected so far by
> submissions from 2.0.devel version of HTTPS Everywhere?
>
> Regards,
>  Ondrej Mikle
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere
>



More information about the HTTPS-everywhere mailing list