WingNews logo WingNews
top | item 13991184

(no title)

aeijdenberg | 9 years ago

If I'm understanding correctly, the plan is to piggy-back on top of the existing Certificate Transparency [0] infrastructure by issuing a regular X509 certificate per Firefox release, but for a special domain name that includes a Merkle tree hash for the files in that release, with a known suffix (".fx-trans.net").

In that manner they can piggy-back on top of the CT ecosystem (including existing logs, including existing search / monitoring tools, and presumably gossip if/when that's solved).

This seems like a really cool hack! The state of binary software distribution is really pretty scary when you think about it - techniques like this have the potential to restore a lot of confidence.

[0] http://www.certificate-transparency.org/

discuss

order

kbenson|9 years ago

Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.

Interesting. I assume this either helped with the evidence for - or was developed because of - the whole Symantec CA dustup going on?

zackelan|9 years ago

Correct. I believe Certificate Transparency existed prior to any of the issues with Symantec, but CT was indeed involved in exposing some of the Symantec shenanigans.

https://arstechnica.com/security/2017/01/already-on-probatio...

> Ayer discovered the unauthorized certificates by analyzing the publicly available certificate transparency log

That article also links to the primary source, https://www.mail-archive.com/dev-security-policy@lists.mozil... which in turn links to a public viewer for Certificate Transparency logs.

tbl|9 years ago

The initial impetus was actually a design to allow a CA to be transparent about its own operations. However, the DigiNotar incident triggered the plan to apply it to all CAs.

lucideer|9 years ago

Knowing quite little about the technicalities behind CT, I'm interested in the scalability of this. If CT were to be piggybacked upon by a large number of open source binary software distributions, I assume this wouldn't be problematic in any way. CT is already designed - I guess - to handle theoretically all domains. Plus, Firefox is a pretty big, popular distribution to be starting with.

aeijdenberg|9 years ago

CT logs are designed to be able to handle queries from all web browsers on a daily / more frequent basis, and the output from queries is easily cacheable (and the logs can be mirrored in a read-only manner).

If FF is already doing any log inclusion proofs for certificates, then I think including one more (for the FF release itself) would be pretty much line noise.

I think an interesting question arises as to how well with the CT logs themselves would scale to handle the same kinds of certificates for all binaries, if this ends up taking off as a good idea in general. They've had to handle quite an explosion in X509 certificates over the past year or two due to Let's Encrypt. Some of Google's logs now show more than 80,000,000 certificates [0] in there - IIRC 2 years ago it was a low single digit million.

[0] https://crt.sh/monitored-logs

tbl|9 years ago

I actually think that building an independent system for binaries is a better plan, for various reasons.

One is that log bloat is indeed a problem, not so much for the logs, but for those that want to monitor them.

The other is CT has made some tradeoffs to allow cert issuance to be quick. I don't believe binaries need the same tradeoffs, and, for example, instead of an SCT, they should come with an inclusion proof (something I'd like to see for certs, too, in the long run).