Certificate Transparency: Public, verifiable, append-only logs(queue.acm.org)
queue.acm.org
Certificate Transparency: Public, verifiable, append-only logs
http://queue.acm.org/detail.cfm?id=2668154
2 comments
Minor correction: this article was written by Ben Laurie, not agl. (Same company though.) But you also mentioned 2011 so I'm not exactly sure what you are referring to.
doh! embarassed. your right, Ben Laurie.
i recall agl speaking about this recently, thats the association. Appologies to Ben and Adam :-)
Your proposal is interesting, but it won't really 'scale'. An attacker can get a _lot_ of value out of a banking certificate, and could possibly continue to "milk the cow" until found, probably collecting more credentials then the associated BTC is worth.
Plus, how are you going to be handling validation? Can I just pay (presumably) a lot less then I would need to crack RSA-2048 (or RSA-1024, given the still-trusted roots) and go on an MITM frenzy?
Plus, how are you going to be handling validation? Can I just pay (presumably) a lot less then I would need to crack RSA-2048 (or RSA-1024, given the still-trusted roots) and go on an MITM frenzy?
Ideally the certificate would be worth, or have a value associated greater than that of the transactions being handled by the site it is protecting; Then the attacker has more to gain by invalidating the certificate than intercepting traffic. Otherwise you have the same situation that we have now with current certificates without a decentralised store of value associated.
Also, every day CA's could sign these certificate requests, and so you have the equivalent to trusted root today. One thing that is advantagous here is that even trusted CA's cannot reproduce a 'trusted' certificate without spending the same amount of cryptocurrency. This would defend against firewall/IPS MiTM that is occuring today.
I brought this whole topic up because of the likeness with blockchains and certificate transparency. My argument is that why would CA's have an incentive to maintain the certificate transparency chain, when you already have many people with an incentive to maintain the bitcoin blockchain.
Validation, or checking for validity of the certificate can be done either through a 3rd party lookup service like blockchain.info or inspection of the blockchain with the wallet software.
I think that adoption of certificates like this would require modification to TLS protocols, or at least some application support to require certain types of certificates - just like EV or Certificate Pinning.
Also, every day CA's could sign these certificate requests, and so you have the equivalent to trusted root today. One thing that is advantagous here is that even trusted CA's cannot reproduce a 'trusted' certificate without spending the same amount of cryptocurrency. This would defend against firewall/IPS MiTM that is occuring today.
I brought this whole topic up because of the likeness with blockchains and certificate transparency. My argument is that why would CA's have an incentive to maintain the certificate transparency chain, when you already have many people with an incentive to maintain the bitcoin blockchain.
Validation, or checking for validity of the certificate can be done either through a 3rd party lookup service like blockchain.info or inspection of the blockchain with the wallet software.
I think that adoption of certificates like this would require modification to TLS protocols, or at least some application support to require certain types of certificates - just like EV or Certificate Pinning.
Not all sites deal with transactions (ex: my personal site). This would pretty much reverse any adoption rates TLS has. (who wants to pay >$200 for a certificate?)
For example, Wells Fargo has like 840 billion in loans. They obviously don't want to pay $800 billion for an SSL certificate, and they'd lose that $800 billion if one file is compromised...
Right now, you can essentially pay to be a certificate authority. This just allows you to pay per site you want to attack.
Right now, you can essentially pay to be a certificate authority. This just allows you to pay per site you want to attack.
Ok, so the date on this paper is 2014, but wasn't this proposed at least 2 years ago? I recall it being proposed as a countermeasure to the Iranian Google cert incident.
Well, the project itself isn't new. But this article is (relatively) new, and since it was quite well written I thought it was worth submitting.
I'm not really knowledgable enough to assess the project's vitality but I found that the Github repo[1] is active, and the mailing list[2] is somewhat active as well. There is also a new RFC draft from 2014-07-10[3].
My conclusion is that since this project is backed by Google, it's currently the most viable attempt to improve on the suboptimal PKI infrastructure we have for TLS.
Ideally Firefox, Safari, Internet Explorer and Opera would add support as well. Firefox as least has an open feature request[4]. But these things take time, you know :)
[1] https://github.com/google/certificate-transparency/commits/m...
[2] https://groups.google.com/forum/#!forum/certificate-transpar...
[3] https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-04
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=944175
I'm not really knowledgable enough to assess the project's vitality but I found that the Github repo[1] is active, and the mailing list[2] is somewhat active as well. There is also a new RFC draft from 2014-07-10[3].
My conclusion is that since this project is backed by Google, it's currently the most viable attempt to improve on the suboptimal PKI infrastructure we have for TLS.
Ideally Firefox, Safari, Internet Explorer and Opera would add support as well. Firefox as least has an open feature request[4]. But these things take time, you know :)
[1] https://github.com/google/certificate-transparency/commits/m...
[2] https://groups.google.com/forum/#!forum/certificate-transpar...
[3] https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-04
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=944175
This paper was written in 2011, and a lot has changed since then. Today, we have an infrastructure similar to what Certificate Transparency is said to produce -- without collusion or support from the CAs. Bitcoin and other blockchain based technologies have an economic incentive to continue to propagate. I fail to see why anyone other than the CA's would have an incentive for the Certificate Transparency blockchain to propagate.
I proposed an alternative model which i called 'UTXOC'. I wrote a paper and published some python scripts to generate certificates based on a prior bitcoin transaction. A certificate validity can be determined by some bitcoin-like value left unspent. If the value is spent, the cert if invalid. If the private key is compromised, the attacker has an economic advantage in 'cashing out' the value; thus invalidating the certificate. I propose that also adds to the cost of key substitution attacks on TLS; an active MiTM would need to spend at least as much cryptocurrency in order to successfully fake a certificate, even with a trusted root in the client.
It could go either way -- with CA support for such things, or a self-signed 'cryptocurrency bond' style model where TLS operators hold cryptocurrency in order to maintain the validity of their certs.
This is published here: https://github.com/MiWCryptoCurrency/UTXOC
Very interested to hear opinions on this, its a work in progress. Yes, support for secp256k1 is limited in mainstream OS's -- it only works with openssl s_client and s_server currently. Given time I hope that the secp256k1 curve is added to browsers and operating systems, and this or similar blockchain based record architectures are adopted.
thanks all ;-)