TLS allows the client certificate to be used to initialise a TLS connection to a server. However, the same can be achieved by:
- Initialise the TLS connection as an anonymous client with a randomly generated private key.
- The server provides a random number as a challenge on a web form or HTTP header.
- 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.
