why a client authentication is not commonly performed in the TLS protocol?

Question

Is there any reason for this other than key/certificate management on the client-side?

Answer 1

What is authentication ? That's making sure that whoever is at the other end of the tunnel is who you believe. It really depends on the kind of identity that you want to use.

For most Web sites, the interesting notion is continuity. They do not really care who is connected; indeed, the point of a Web site is to be readable by everybody. The kind of authenticity that a Web site wishes to achieve is to make sure that two successive requests are really from the same client (whoever that client may be). This is because the Web site experience is that of a logical succession of pages, driven by the user's actions (the links on which he clicks), and meddling with that movie-like framework is what the attacker is after. The user and the Web site designers think in terms of sessions and the attacker wants to hijack the session.

This authenticity is achieved by several mechanisms:

• Successive HTTP requests from the same client go through the same connection (with the "keep-alive" feature).
• SSL offers a session resumption mechanism, which reuses the negotiated shared key (that's the "abbreviated handshake" described in section 7.3 of the SSL/TLS standard).
• The HTTP request can include a cookie which the server chooses; typically, a random, user-specific value is sent as a cookie to the user, and, upon seeing it coming back in subsequent requests, the server is convinced that the requests come from the same user.

The cookie is sufficient to ensure continuity.

What extra value would client certificates add ? Well, not much. Certificates are a way to distribute key/name bindings. There are mostly three scenarios where client certificates (in a Web context) are relevant:

1. The Web server needs an extended notion of user identity, which is defined by someone else. For instance, imagine a governmental service that can be accessed by citizens, but only after proper authentication, e.g. an online election system. What makes the citizen, with his definite name and birth date, is managed by the State at large, but not the same part of it than the one running the service. Client certificates are then a way to transport the authentication from the PKI which issued the certificate to the citizen, to the online election system which is not at all entitled to say who is named what, but must nonetheless keep clear records of who connects.

2. The system designer has little trust in the robustness of existing Web browsers. If a user's browser is hijacked, then the secret cookie can be stolen and the user has basically lost, forever. On the other hand, if the user has a smart card, and that smart card stores a private key (which is used in combination with a client certificate), then a complete browser hijacking is still a big issue, but it is more contained: since the smart card will commit honourable seppuku instead of letting the precious private key be revealed, the situation can be recovered from. Once the mandatory format-and-reinstall has been performed, things are secure once again.

3. The Web site does not only want authenticity, it also wishes to get non-repudiation. Non-repudiation is a legal concept which needs some support from the technical parts of the system, and that support is digital signatures. We are outside of what SSL/TLS provides, here. In no way can a SSL/TLS client authentication be a proof which could be used to resolve some legal conflict between the user and the server itself (a bank server cannot show the transcript of the connection and say "see, that user really asked me to buy these actions at that price", because the bank could easily have fabricated the whole transcript). For such things, one needs client certificates and some client-side code which uses the certificate to sign the actual data. However, once the hard work of issuing certificates to clients has been performed, it makes sense to just use them for HTTPS.

In the common case of a Web server, none of these scenarios apply. So client certificates are not used, because they would raise practical issues while not adding any extra value. That would be a solution in search of a problem.

Answer 2

The primary reason is that 95% of internet users have no idea what a client-side certificate is, let alone how to use one. Some users can barely manage to use usernames and passwords, and most still don't bother with two-factor authentication. It's also a hassle to install a client certificate on separate devices (desktop, laptop, tablet, smartphone, etc.) for authentication to a single service.

So, for a quick list:

• Ignorance. People just don't know what they are or why they're useful.
• Convenience. People can't be bothered to configure their device to use client certificates.
• Support. If people today still have to phone up tech support when they forget their password or can't log in, can you imagine how many more support calls will be required if they have to install a client certificate? This problem is multiplied even further by Internet Explorer's market share dropping, so staff need to be trained to guide users through installation on IE, Firefox, Chrome, Opera, Safari, etc. plus various mobile devices.
• Complexity. Additional server-side code is required to validate the certificate in relation to a user account.
• Prevalence. No major sites are using them en-mass yet, so nobody else will. I realise this is a catch-22, but technology adoption often is.
• Complacency. Most vendors assume passwords (or 2FA) are strong enough for their purposes, even when those vendors are protecting highly sensitive / critical information such as financial data.

So, whilst it would be nice to see client-side certificates on a large scale, I really don't see it happening unless a serious event pushes vendors into doing it.

Answer 3

The client is trying to reach a specific server, identified in the URL. So the client needs to authenticate the server.

On the other hand, in most uses of HTTPS, any client can contact the server. The server doesn't have any prior knowledge of the client. So there is nothing for the server to authenticate the client against. The server wants to authenticate the user, not the client machine.

In an Internet setting, the client may be behind a proxy, on a dynamic IP address, etc. There is nothing that the server might want to verify. The only point of authenticating the client would be to record its identity for future uses, either for forensic purposes or to track clients across multiple connections. Since users may connect from multiple machines, there is not much point in tracking client machines. Recording client identities is only very marginally useful to identify malicious clients or users after the fact (the attacker is likely to have generated a certificate that doesn't provide any useful information), it isn't worth spending any effort.

In an intranet setting, where only known clients should connect to the server, client authentication is useful and is used.

Answer 4

In cases like Gmail, Yahoo and other web apps that use PKI to authenticate servers, client authentication is not done using certificates, but instead uses simpler authentication such as user/name passwords. Think about this. Your browser can store x number of certificates for the various CA's, and the websites out there. But can Gmail hold certificates for its millions of users ? It is simply not scalable.

This is a very simplified answer as to why client certificates are not used. However, when you SSH into a server, client certificates are/maybe used.