Is 2-way tls/ssl safer than Client ID enforcement? This is an interesting question. In some organizations or fields 2-way tls/sslis mandatory. When asked what the exact benefits are it’s mostly because it complies with regulations, it’s the standard and the secret never crosses the wire. But what is really the difference between these two standards.
Both protocols are used on top of 1-way SSL (or 1-way TLS). Where 1-way tls/ssl is used for setting up a secure tunnel and verifying the identity of the server.
Since you want to restrict access to your resource (API) you want to know the identity of the client. This is where client id enforcement and 2-way SSL come in too play. The usage of one of the two does not increase the strength of the secured tunnel tls/ssl.
1-way-TLS/SSL
First the client sends a hello message. The hello message is used to agree on the encryption protocol. The public certificate is send by the server . The client validates the public certificate checking the CA (Certificate Authority). The truststore normally has a set of CA’s which are trusted ‘out-of-the-box’. So normally a public API or website uses one of these trusted CA’s as an authority for their certificate. Therefore most of the time for one-way tls/ssl there is no need to send the complete CA chain to the client. The CA is used to determine whether the certificate can be trusted. The client now sends a secret key to the server. And the server uses his private key to encrypt this secret and sent it back to the client. In case of two-way-ssl the server will also request the certificate of the client. In the case of client-id enforcement the SSL handshake is now completed.
If you want more background information on this you can go to: https://cheapsslsecurity.com/blog/what-is-ssl-tls-handshake-understand-the-process-in-just-3-minutes/
2-way SSL
In case of 2-way tls/ssl in the ‘final step’ of the handshake the server requests the public certificate of the client. If the certificate has not been signed by a trusted CA then the complete CA chain must be send a long so that the server can validate the certificate. The server will now validate the client certificate thru the CA. Now the secret key will be encrypted using the public key of the client certificate. In the final step the client will decrypt the secret using his private key.
Client ID enforcement
In order to make use of Client ID enforcement the client will first have to make a request to the service provider in order to receive the client-id and client-secret. Via a secured portal the client can make this request and the client-id and secret will be provided to the client. In this case these keys are made available in a secure manner. Both the Client and Service provider are capable of discarding these keys.
After the one-way tls/ssl tunnel has been created the client-id and secret will be send a long in the headers. The service provider will than check if these are valid and the connection has been made.
Advantages and disadvantages
Let’s take a look at some of the advantages and disadvantages of these two protocols.
Key requests
An advantage of client ID enforcement is that both parties are in control of the keys. The exchange of the keys take place in a secure manner. For 2-way-tls/ssl it is up to you to securely exchange the certificates.
Key exchange
The private keys are never exchanged using 2-way tls/ssl. With client id enforcement the client-id and secret are send to the service provider through the secured tunnel that has been setup earlier. But the exchange of these keys between client and service provider are not visible for a third party.
Administration
When using client id enforcement both parties are capable of requesting new keys. For 2-way tls/ssl it’s up to the one holding the private key to revoke a certificate. Also using 2-way tls/ssl it’s mandatory to replace the certificates when the validity of the certificates expire. With client-id enforcement however the client id and secret are basically valid forever. However you can implement a policy. You could for example implement a policy that these certificates have to be renewed every year. But that’s up to you.
Conclusion
Security wise I don’t think there is a clear winner . Yes, it’s true that for 2-way ssl/tls the private key never crosses the wire. So in the event that the public key is captured then it’s still not possible to take on the identity of the client. This is because the private key of the client is needed to decrypt the secret key that was agreed upon.
However, it is mainly about how you handle the storage and transport of the keys. If you do not store the certificates and keys securely, then it really doesn’t matter which protocol you use.