1

TLS allows the client certificate to be used to initialise a TLS connection to a server. However, the same can be achieved by:

  1. Initialise the TLS connection as an anonymous client with a randomly generated private key.
  2. The server provides a random number as a challenge on a web form or HTTP header.
  3. The client, e.g. a browser, utilises the private key (through window.crypto javascript API) to generate a RESTful API call to identify itself to the server by signing the challenge and providing certificate.

Is the two method: client certificate and javascript-API call, the same in terms of security?

The scenario behind this question is that we are using blockchain public key to establish a TLS connection. Since there is no client certificate signed by the authority, the client gives a Merkle tree path as proof instead.

Apparently, the format of such a proof is not understood by the HTTPS server when used as a replacement for the client certificate, so we are modifying the server.

Then someone brings up the question: is there any security advantage we can gain to implement Merkle tree proof as client certificate at all? It looks perfectly safe if we implement it on the business logic layer by starting with anonymous TLS connection then requires authentication.

I started to realise that there are other advantages to do authentication after TLS connection is established, e.g. it gives the opportunity for a greater user interface, for example, by displaying messages like this "Your Merkle proof seems to point to the test net - we only accept main-net Merkle proof."

Then I ask myself, what was the reason to use the client certificate to initialise TLS in the first place? Why TLS includes the concept of initialising TLS with client certificate at all? It looks only to make systems harder to use without security advantages.

  • 4
    A blockchain public key for TLS? Huh? – forest Jun 19 '18 at 7:47
  • 4
    I don't think you understand how TLS handshake works. By default the client does not authenticate itself (i.e. anonymous) and there is no need to use a random private key to achieve this. – Steffen Ullrich Jun 19 '18 at 8:26
  • 3
    I'm not understanding why you are talking about Blockchain. Basically, you can use blockchain to define a set of authorities that releases X.509 certificates to their clients, and after that these clients could use these certificates to perform authentication, negotiate a key with other clients and so on. But use these certificates in TLS, it doesn't have a sense. – CipherX Jun 19 '18 at 9:43
  • It sounds like you're modifying the TLS protocol in some way to suit your own needs. Like others, I'm confused why you're bringing up blockchain technology here, so that leads me to believe you've gone outside of the normal TLS protocol. That's normally a bad idea. – Steve Sether Jun 19 '18 at 15:20
  • There is no authority to sign it in the case of the blockchain. If you own a token from a smart-contract, the only thing to prove it is a Merkle path to the event, since the smart contract, with gives the "certificate", doesn't have its own private key. It's not a person and it has no secrets. – Tankman六四 Jun 20 '18 at 3:16
2

Is the two method: client certificate and javascript-API call, the same in terms of security?

Both methods rely upon the client having a private key signed by some authority that the server trusts. So in theory, they can be equivalent - in practice, the TLS library code of the client is probably much more vetted than whatever API you're going to scheme up. That's not to say you can't make it secure; just be careful and get it reviewed by people who understand crypto.

Then I ask myself, what was the reason to use the client certificate to initialise TLS in the first place? Why TLS includes the concept of initialising TLS with client certificate at all? It looks only to make systems harder to use without security advantages.

TLS client certificates are an optional, inline method of providing authentication. You are viewing the inline part of that as a negative, because you'd like to be fancy and do something different. However, for many uses, that inline aspect is a plus.

The sort of contortion you're proposing, where you're adding an application-layer step, is only useful where you've got control of the client, the server, and the protocol. But recall that TLS has been a bolt-on security layer which has often been used for applications and protocols that have no idea it's being used, where there is no ability to execute custom code on the client. For those situations, having a uniform and reliable method of client authentication baked into the libraries is a huge win.

  • Exactly. Just a particular: TLS clients certificates are used to provide mutual authentication. – CipherX Jun 19 '18 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.