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

User logs on to website or creates an account.

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.

The client side cert is signed by the server and imported into the web browser for the purpose of client authentication

The server registers details of the client certificate (thumbprint / hash / public key) and will use it later for session verification.

Authentication

The user logs on to the website (n+1 visit)

The user is prompted for a client certificate

The server verifies the client cert.

Mutual TLS is established.

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.

2 Answers
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:

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.

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.

The specific threat I had in mind was TLS access over untrusted Wifi networks (or cellular networks) that can be intercepted and modified by a rogue CA. Would client certificates assure me safe surfing while at a hostile location (free Wifi access at defcon ?)
–
LamonteCristoJan 13 '13 at 20:41

1

A client certificate would not give you such safety by itself. It is the job of the server: in SSL, the client does not use any certificate until the server asks for it, and most server do not. If the server requires a client certificate and rejects connections which do not present one, then your connections will be "safe". However, you envision a setup where the attacker could insert a rogue CA in your trust store. This requires admin rights on your machine. This means your machine was "owned". Under these conditions, that machine cannot be considered as "safe" anyway.
–
Thomas PorninJan 13 '13 at 21:24

I should update my question and specify my threat model. I'm interested in protecting myself from a rogue CA certificate (Diginotar hack), without adding certificates locally, or compromising the local machine. Yes, server side validation will have to tie the browser certificate to the end user session, and enrolling a browser certificate into such a session is key to prevent this type of MITM.
–
LamonteCristoJan 13 '13 at 22:34

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.

My threat model is to protect against a malicious CA that happens to be in the default trusted roots, or a SubCA of one of them. Perhaps it's a misconfigured CA who issues End Entity certs without that basic constraint marked.
–
LamonteCristoJan 14 '13 at 5:11