search

namecoin / meta

General-Purpose Namecoin Repository
4 stars 3 forks source link

BTLS: Blockchain-based Transport Layer Security #12

Open renne opened 9 years ago

renne commented 9 years ago

I want to suggest a simple-to-implement and easy-to-use blockchain-based authentication method:

Registration of ID/username/pseudonym

  1. User registers an ID/username/pseudonym in 'id/'-namespace
  2. User presses a button in blockchain client to automagically generate a self-signed X.509 client-certificate (PKCS12-format) which uses the ID as Distinguished Name and adds/updates the fingerprint of the client-certificate as application in the blockchain
  3. User imports self-signed X.509 client-certificate to his application (e.g. browser)

Authentication:

  1. User connects to service via (D)TLS
  2. Service requests self-signed X.509 client-certificate via (D)TLS
  3. Service validates self-signed X.509 client-certificate via ':<X.509-fingerprint>'-tupel in blockchain instead of CA-root/-intermediate certificates

That way there is no need to have a blockchain-client running on client machines for authentication and we can use existing client-side infrastructure without any changes (e.g. browsers, embedded systems, ...). As Proof-of-Concept I suggest to patch STunnel for server-side client-certificate validation and to develop an Apache authentication provider module.

ToDo:

  1. Namecoin protocol: Add X.509-fingerprint for (D)TLS as registered application in 'id/'-namespace definition.
  2. Namecoin-QT: Add button per ID in "Manage Names"-table to create and register self-signed X.509 client-certificate (Issue 195).
  3. Patch STunnel to authenticate self-signed client certificates against the blockchain instead of CA-hierarchy.
  4. Apache webserver: Develop authentication provider module 'mod_authn_blockchain'.

Discussion in Namecoin-Forum

Documentation for Namecoin-/Blockchain-newbies: Wikipedia about Blockchain Bitcoin.it about Blockchain Namecoin protocol (Blockchain implementation) Namecoin Identities Namecoin client (Source code)

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/6114852-btls-blockchain-based-transport-layer-security?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).
phelixbtc commented 9 years ago

Very interesting!

JeremyRand commented 9 years ago

This would certainly be cool. Seems to be a cleaner and more standard solution than the NameID browser extension.

How well do web browsers handle client-side TLS certs? (I've never used them.) Is it possible for a web browser to store more than one TLS cert for a single website and let the user choose which is used? Does the user have control over whether a cert is sent at all?

I vaguely recall that Convergence has some bugs that prevent client-side certs from working properly; this would be a nice excuse to fix that.

renne commented 9 years ago

I'm using Firefox to login at StartSSL. When importing the StartSSL client-certificate into Firefox I was just asked for the password once. When I went to the StartSSL login-website for the first time Firefox presented the matching client-certificates and asked which one to use. Since then login works automagically. Only when I re-install Firefox I have to export/import the client-certificate - or after the two-year expiration period. ;)

JeremyRand commented 9 years ago

So, do I understand correctly that it's not easy in Firefox to switch between multiple certs for a single website (e.g. if you have multiple id/ names and wish to keep your identities separate)?

renne commented 9 years ago

In extended settings of firefox you can choose if it selects certificates automatically or asks every time you visit websites.

JeremyRand commented 9 years ago

@domob1812 , can you comment on any advantages/disadvantages that this method would have compared to the NameID browser extension?

domob1812 commented 9 years ago

In principle, I think that this is "similar" to NameID: Authentication to a server is done by a key pair instead of password, and the key pair is pinned to the Namecoin blockchain. The difference is the actual implementation - for NameID, the keys are ECDSA keys associated to Namecoin addresses. For this proposal, they are X.509 client certificates.

However, obviously X.509 certificates have a huge advantage in terms of existing software support. I've never tried to configure a server to accept them, but I guess that it is a standard procedure and easier to do for most admins out there than it would to add NameID support. The same goes for the browsers - they have client certificate support already included. I've used them also for StartCom as well as CAcert, and the experience is quite pleasant. (Except for the "conflict" I get when I want to protect client certificates by a master password in Firefox, but that makes FreeSpeechMe ask for the passphrase every single time I open a browser window.)

In fact, I always envisioned the signer field of id/ names to be not restricted to addresses - the spec can very well be extended to allow all kind of keys to be specified there, including GPG fingerprints as well as X.509 certificates. This is, IMHO, a very good idea and something that "just" needs to be implemented by someone.

renne commented 9 years ago

NameID is a great idea. But my first question was: Who operates the OpenID-servers interfacing between the blockchain and the TLS-application-servers (DNS-dependent domain, costs, administration, support, reliability, ...)? In this approach TLS-application-servers validate the self-signed client-certificate directly against the blockchain. This avoids additional centralization by OpenID-servers.

I also proposed a protocol extension in the Forum:

domob1812 commented 9 years ago

The actual idea behind NameID (for the future) is and always was that server operators can include the verification directly for themselves, instead of relying on OpenID. Then the fundamentals become, more or less, the same as your proposal. But I see a lot of value in the X.509 idea in that it allows to reuse a lot of existing implementations. Unfortunately, I've not really much experience with X.509 except as a user of client certificates in the browser and as a server admin who just set up TLS (without client certificates) on Apache. I think your idea of implementing an Apache module and all that seems like a really cool thing, if you or someone else can do it!

renne commented 9 years ago

1.) Does libcoin have all necessary functions/compatibility to query and validate data from the Namecoin-blockchain? 2.) Does everyone agree with my application proposal?

domob1812 commented 9 years ago

1) Yes.

2) I would prefer to extend the signer field instead of adding a new field. After all, what you have in mind (linking a key for authentication purposes) is precisely what signer is about. On the other hand, if you propose this new field to represent (mostly) a certificate for, say, S/MIME, then a separate field makes sense. Apart from this detail (which should be discussed separately and the spec updated accordingly), your plan sounds fine.

renne commented 9 years ago

Please move the application discussion to the forum!

Creating a self-signed X.509 client-certificate with OpenSSL and C/C++

HutchSails commented 9 years ago

I think that a modification to the client that added a tab for DNS names (versus generic names) would make for a much more uniform domain name system data set.

There were quite a few aberations in the sample I polled, including missing dots in the IP addresses, etc.

I looked at the last five thousand blocks, and found only 14 entries with fingerprints. So - the suggestion to incorporate a builder for certificates is good, and may encourage more people to put authentication bits into the blockchain. It's the authentication that makes this DNS subproject attractive.

JeremyRand commented 9 years ago

@HutchSails Can you start another issue for that discussion? It's a good discussion to have, but somewhat off-topic for this thread. Thanks.