Should the Keygen element be used to create a certificate for mutual auth TLS? What alternatives are there?

Question

I'm interested in using mutual auth TLS to improve the security of my javascript based webservices . I've looked at the Keygen element and given all its issues, not sure if this can even be used for this purpose.

If I'm right in thinking that mutual auth TLS is one of the more secure forms of TLS (to put it simply), is it reasonable or a good idea to use the cryptographic material sent by Keygen for this purpose?

---

Update:

My threat model is to protect from a Diginotar-style attack. The solution would look like this:

Enrollment

1. User logs on to website or creates an account.
2. If the machine has never been seen before (new account) instead of adding a persistent cookie, the user is prompted to create a client side certificate.
3. The client side cert is signed by the server and imported into the web browser for the purpose of client authentication
4. The server registers details of the client certificate (thumbprint / hash / public key) and will use it later for session verification.

Authentication

1. The user logs on to the website (n+1 visit)
2. The user is prompted for a client certificate
3. The server verifies the client cert.
4. Mutual TLS is established.
5. The server verifies the authenticated call with a known client certificate. If the calling certificate is blank or from another user, then a MITM may be being performed and access is denied.

Answer 1

I think that there are many disadvantages in using the keygen element, as it is already enumerated in your post. If you have a webservice that should be easily accessible and compatible with a lot clients, it is quite hard to implement client-side authentication using keygen, a solution that is quite new and not very mature.

The best solution would be to provide cryptographic tokens to your clients, with preloaded certificates, signed by your CA. Of course, this adds a lot of complexity, because you have to manage the generation and distribution of the client certificates, which may be very hard to do if you have many clients and no infrastructure for a CA. The advantage of this solution would be a very strong authentication mechanism for your clients.

If you are just trying to prevent MITM attacks, using SSL and a good user/password access mechanism may be enough in most cases.

It depends a lot on what are the resources you have, what your are trying to protect and against whom and who are the users of your application. Answering this questions would be the first step in the process of building a secure systems.

---

Update:

In regards to the threat model you have described, I do no think that your model will offer protection against compromised CA. Here is an example:

• A CA is compromised and a certificate is issued for your domain
• The DNS of the client is compromised so that it responds with the IP of the attacker, when queried for your domain
• The client tries to connect, it establishes a connection with the rogue server, which in turn connects to your server
• The rogue server acts as a client that connects from a new device and a new client certificate is generated.
• Even if the real client sends his existing certificate, the rogue server would ignore it.

The attack described above assumes that a client can have multiple certificates (one for each device he is connecting from). If you do not want to implement this behavior, then it would be quite hard for a regular client to copy the certificate to every device he is using and of course, a bad user experience .

All in all, protecting against compromised CAs is tough business, and I think that as long as new technologies as DNSEC are not implemented at a large scale, there is not much one can do.

On the other side, the hacking of a well known CA is not something that happens every day. Just be sure that you do not buy a certificate from a noname CA and you should be secure enough for the moment.

Answer 2

To do certificate-based client authentication with SSL, the client must "own" a certificate, i.e. have access to a private key and the corresponding certificate (issued by a CA that the server will accept). When the client is the Web browser, there is no way to escape it: the browser must know the key as such.

There are two ways for the browser to "know" a private key + certificate pair:

1. Have the CA generate the key pair, create the certificate, and package the whole as a PKCS#12/PFX file which is then imported in the browser.
2. Have the browser generate the key pair, send the public key to the CA, which generates the certificate; the certificate is then imported in the browser.

The second method is often deemed "better" in a generic way. In particular, if the certificate must be used later on for signing documents, in a legally binding way, then the details of the key lifecycle are important for the legal value; the details are complex and depend a lot on local laws, but, as a rough summary, if the private key ever exists, even in a transient way, on a system other than the user's computer, then it won't work. However, in an authentication scenario, especially for a SSL/TLS session, this might not be a problem.

The <keygen> element is the HTML5 way of implementing the second model. It is actually rather older than HTML5 and has its roots in Netscape Navigator. See this page and that file for details on how to use it. For Internet Explorer, you will have to use a Microsoft-specific way, which was called Xenroll but has been deprecated in favour of CertEnroll (see this blog post for an introduction). Microsoft has proven reluctant to implement <keygen>, officially because they don't like what it does.

Anyway, if you do SSL-level certificate authentication, then you must contend with the kind of user interface and experience that the browsers support -- which is not utterly optimal from an ergonomic point of view. Alternatives include doing some authentication within the SSL tunnel, which, in a Web context, means either something which the user types in (passwords or click-o-matic equivalent) or Javascript tricks. The problem with Javascript is that it does not have access to the client OS repository for private keys (and interface to smartcards) unless some non-standard features are used.

Certificate-based authentication in SSL/TLS is not necessarily "more secure" than other methods of authentication. Certificates allow for separating identification from authentication. It is a nice feature but is useless in systems where the overall architecture does not call for such separation.