Foaf+ssl/Clients

From W3C Wiki

SSL/TLS is a core part of the Web, and client certificates is very important for security conscious organisations. As such it is implemented in all high volume browsers. Before the development of FOAF+SSL though, client certificates were used in a very limited setting. Usually a client cert would be used only on the site that had released it and to a small extent on partner sites. As such the user interface for client certificates has not been very carefully worked on, especially the option of using one certificate across many sites. Remarkably enough, creating certificates on most non mobile platforms can be a one click affair. Below we list the issues with various browsers, how to create certificates, and what UI improvements would be helpful.

Using Certificates to Authenticate

The Certificate Selection UI page shows what the certificate selectors look like on each platform.

We keep testing login on a number of browsers. The following allow foaf+ssl login.

  • Internet Explorer 6/7/8: does a good job presenting a choice of certificates.
  • Firefox: all versions of Firefox tested work with foaf+ssl. User interface improvements can be made quite easily, especially in the certificate selection box, which presents too much irrelevant information
  • Opera: all versions of Opera work with foaf+ssl client side certificates. The interface for selecting client certificates is much better than that for Firefox.
  • Safari
  • WebKit is the open source version of Safari for OSX. The latest development snapshots (March 2010) allow one to log-in to any foaf+ssl enabled site, but one is not offered to choose which certificate to use, which is a major user interface issue.
  • Google Chrome currently works on Windows, and the since March 16 2010 the dev snapshot work for OSX, after fixing issue 37765. The remaining issue 29784 for UI improvement is all that is left to do.
  • Konqueror Not sure if it works or not, but posted a improvement request nevertheless
  • Fennec (Firefox Mobile) tested successfully using windows and OSX emulator. The keygen tag and the client cert negotiation work perfectly. There are clear user interface improvements that can be made, as described on "foaf+ssl in Mozilla's Fennec works!"
  • Flock (Social Browser) tested successfully including import from firefox on startup.

Problematic Browsers

  • trying keygeneration and authentication on Android does not seem to work. See issue 66342

Support for easy creation of certificates

There are three ways of implementing certificate creation, depending on the browser: using <keygen>, using JavaScript or via ActiveX. All generate the key pair locally, send the public key to the website, which then responds with the X.509 certificate (signed by the server) for the browser to import into its keycchain, tying it back to its original private key.

Keygen

The <keygen> approach is the one that works in Mozilla, Firefox, Safari and Opera (at least). The original <keygen> element was developed by Netscape all the above but not by Internet Explorer. It was formally standardised in the HTML 5 spec.

The html element can be placed in a form with a challenge. When the user submits that form the browser generates a public/private key pair and sends the key request - consisting of the public key and the challenge signed by the private key - to the server in the POST along with the other fields from the form. The requirement to sign the challenge can assure the server - who will be certifying extra information placed in the certificate, that the key request was tied to that session. {{{ But what could a client do with a certificate for which he did not have the private key? }}}

Limitiations:

  • keygen uses insecure Md5. But this is mitigated by the fact that the Challenge can be time based, requiring the signature to be cracked with a few minutes.
  • does not seem to work on many of the mobile browsers, except Fennec (Firefox Mobile). As workaround for the iPhone browser, one has to e-mail oneself the password protected certificate (in a PKCS#12 file), as described in the article How to get a foaf+ssl certificate on the iPhone.
  • does not work in xhtml in Firefox, see the JavaScript workaround below, this report

JavaScript

In Firefox, some CAs tend to prefer the JavaScript generateCRMFRequest function, which has more capabilities, like its ActiveX counterpart. But this requires Javascript to be enabled in the browser (see also browser generated certificate requests).

The Javascript method is the only way in current versions of Firefox to generate keys when producing xhtml pages (conf this report)

Active X

Internet Explorer does not support <keygen>. Instead, key-pair generation has to be done using ActiveX controls using JScript. These calls must rely on the XEnroll API on Windows XP and on the CertEnroll API on Windows Vista, 7 and Server 2008.

Code

All of these are implemented in the Apache keygen module, a Java OSGI component. A client side implementation can be found in Clerezza's Account Control Panel, which uses all of the above methods to maximize the number of clients on which keys can be produced.

Alternatives

Alternatively, if in-browser key generation is not possible, a .p12 (PKCS#12) file could be created on the server side. The disadvantage of this approach is that it the private key is known, at least temporarily, to the server that generates this .p12 file. This is often considered a security risk and appropriate trust in such a service would be required, since it could potentially store any of the private keys of its users.

Further User Interface Issues

None of the browsers currently allow one to easily stop using a certificate, once one has chosen to use it with a web site. If one only has one certificate this is not a problem. As soon as people find they want more than one persona on the web - more than one WebId - this will be a pain. What is required is not much: just as the browser shows the user what certificate the server sent it and how trusted it is, so the browser should show what certificate was used for the site the user is on. It should be easy for the user to disable that choice, or ask a different certificate to be used with that site from then on.

See:

The worst browser currently is Safari/WebKit, which does not ever allow the user to change the certificate used for a web site - not without going to the Keychain.app and doing some very unlikely vodoo. Luckily though Safari does allow server side logout. But the other browsers have problems with this:

Further down the road browsers could use the WebId in a certificate to fetch information from the FOAF profile, and display an icon, name or other information about the user as a mnemonic. It could also color code the security of the certificate, as clearly a simple HTTP certificate could be prone to a man in the middle attack.

Javascript Login/Logout

Logout is possible using javascript with some browsers, Firefox and IE.

Browser tips and tricks

Firefox

When helping someone to find out if they have a certificate for their Web Id, they can enter the chrome://pippki/content/certManager.xul URL in the Firefox bar, and it will get them to a page listing the certificates used by their browser. Have them click the "Your Certificates" tab. This is easier than walking them through the menus. ( from the Mozilla Zine Chrome URLs page )

Hardware security

To increase security X.509 certificates and their private keys can be placed on external hardware connected to the computer, in such a way that the private key cannot be read by anyone. The hardware does the encryption calculations and sends the result to the user agent. As a result, the possible loss of the private key is much reduced and much more visible, as it is directly tied to the loss of a piece of hardware.

There are many different types of hardware on the market. Please report back to the list with any experiences using these in combination with foaf+ssl. Some that we know of are mentioned below.

Privacy Foundation.de

German Privacy Foundation Crypto Stick

German Privacy Foundation develops and sells the CryptoStick. It is based on the OpenPGP Card. Both the hardware and software of the Crypto Stick are available as open source. It is compatible to a large amount of open source applications.

See the video WebID & The Crypto Stick to get an idea both of where things stood with this key in May 2011 and where they could go with more OS support.

Safenet e-Tokens

Safenet proposes a range of Certificate Based PKI USB Authenticators as well as Certificate based PKI Smart Cards


Other Resources

The Keygen2 proposal is looking at extending key generation in a wide number of ways