Revocable, Self-Signed TLS Certificates(github.com)
github.com
Revocable, Self-Signed TLS Certificates
https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack
2 comments
Ok so a naive attack would work this way:
1. Create many certs for many different domains, each with a different Bitcoin address.
2. Send an amount of bitcoins to each address.
3. If in the future legitimate domain owners create legit certs, the attacker could present his own malicious cert and victims could potentially accept the malicious one as legit even when they are aware of the more recent legit cert, because the malicious one is older.
Pros and cons of the attack:
- Pro: There are no permanent costs to this attack, only temporary ones. Bitcoins have to remain in these addresses for the duration of the attack(s), but the attacker can get his coins back afterward.
- Con: The attacker can attack only a limited number of domains, as more and more coins become needed.
- Con: Malicious certs must be created earlier than the legit certs
So perhaps users should not trust certs that have been created earlier, but those that have the most coins locked in. But then nothing prevents an attacker from creating a cert with many coins (more than what the legit owner spent) to perform an attack for a few days, then later get his coins back when he doesn't need the cert any more.
So really there should be a fine balance when evaluating these 2 properties: trust old certs that have many coins locked in. But sometimes trust newer certs if they have more coins locked in. But not too new or else it might just be a sign of an attack. This fuzzy logic would probably cause many false negatives or false positives that ultimately could make end-users not trust the system.
1. Create many certs for many different domains, each with a different Bitcoin address.
2. Send an amount of bitcoins to each address.
3. If in the future legitimate domain owners create legit certs, the attacker could present his own malicious cert and victims could potentially accept the malicious one as legit even when they are aware of the more recent legit cert, because the malicious one is older.
Pros and cons of the attack:
- Pro: There are no permanent costs to this attack, only temporary ones. Bitcoins have to remain in these addresses for the duration of the attack(s), but the attacker can get his coins back afterward.
- Con: The attacker can attack only a limited number of domains, as more and more coins become needed.
- Con: Malicious certs must be created earlier than the legit certs
So perhaps users should not trust certs that have been created earlier, but those that have the most coins locked in. But then nothing prevents an attacker from creating a cert with many coins (more than what the legit owner spent) to perform an attack for a few days, then later get his coins back when he doesn't need the cert any more.
So really there should be a fine balance when evaluating these 2 properties: trust old certs that have many coins locked in. But sometimes trust newer certs if they have more coins locked in. But not too new or else it might just be a sign of an attack. This fuzzy logic would probably cause many false negatives or false positives that ultimately could make end-users not trust the system.
The technique is not about the initial validation of a self-signed certificate, its about a pinned self-sign certificate that you trust but want to be able to revoke in the future.
I think you're forgetting about the CA. Why would the certs you created be signed by a CA clients respect?
This seems somewhat related to some work I did last year on using blockchain to 'register' and provide distributed revocation of certs. I called it UTXOC or Unspent Transaction Output based Certificates
https://github.com/MiWCryptoCurrency/UTXOC/ Specifically, I called 'self-signed' certs 'Cryptocurrency Bonds' and could be revoked by spending the funds associated with a public key (bitcoin-like address), and others could verify this by inspection of the blockchain.
The difference here is that I was using the cert privkey as as the bitcoin privkey; Problem being that modern browsers don't and likely never will support the secp256k1 curve for EC keys in TLS. I did built a custom NSS+Firefox that did, and it worked, so it is possible. In fact, NSS used to support the full range of EC curves until 2005. https://raw.githubusercontent.com/MiWCryptoCurrency/Certific...
Would be great to discuss your thoughts on using blockchain for x509 and trusts.