

Revocable, Self-Signed TLS Certificates - mrb
https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack

======
MiWDesktopHack
Hiya,

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/](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...](https://raw.githubusercontent.com/MiWCryptoCurrency/CertificatesInBrowsers/master/%28working%29-SECP256K1-certificate-
in-firefox.png)

Would be great to discuss your thoughts on using blockchain for x509 and
trusts.

------
mrb
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.

~~~
kaffee
I think you're forgetting about the CA. Why would the certs you created be
signed by a CA clients respect?

~~~
chc
Aren't we talking about self-signed certificates per OP?

~~~
upofadown
The revocation of self signed certificates, yes...

