396709 - tracking unsuspecting users using TLS client certificates

Status: RESOLVED DUPLICATE of bug 395399

(Firefox :: General, defect)

Description

[u88484]

Attachment: Proof of Concept

The below is quoted from the above linked page...



... I realised that you can do something with Firefox 2.0.x that
you could not do with Firefox 1.5.x: track an unsuspecting user
using TLS client certificates.

Here is how it works:
- The user visits a websites and leaves behind some personal data
  (for example on a registration form).
- The website uses SPKAC using the <keygen> tag to create a private
  key for the user. This will pop up a dialog that says:
  "Key generation in progress ... This may take a few minutes ...
  Please wait ..."
  With a 1024 bit key on a modern machines, this only takes a few
  seconds, so it is barely noticable to the user.
- Using the SPKAC data, the website creates a TLS client certificate
  for the user (which may contain just a unique identifier for the user
  and/or the personal data entered) and sends it to the user using the
  "application/x-x509-user-cert" MIME-type. Firefox will automatically
  install the certificate and pop up a dialog that says:
  "Your personal certificate has been installed. You should keep a
  backup copy of this certificate."
  This dialog may need some social engineering from the website to
  keep the user unsuspecting. But who has actually heard of a
  "personal certificate" except for the more technical users? One
  could even explain to the user what it really is without the user
  knowing that it will mean trouble for him.
- Because Firefox's standard configuration is to automatically choose a
  TLS client certificate to be sent out, the certificate including
  the personal data will now be sent out to any website that requests it.
  Contrary to a typical cookie, this includes websites that are on a
  completely different domain. The user will not notice this at all.

Caveats:
- The user has to have saved a password in his password safe before.
  Otherwise, Firefox will ask the user to choose a password for the
  "software security device" during the SPKAC key generation.

What other browsers do:
- Firefox 1.5: Does not allow you to install a client certificate that
  is from a CA which you don't trust. I still believe this was a decent
  default setting.
- Opera: During the key generation, it asks for "a master password to
  protect your client certificates in Opera". Note the wording, which is
  IMHO much more clear than the password for a "software security device".
  During installation, it asks whether you want to install the certificate
  and pops up another dialog "Are you sure you want to trust this issuer?".
  Before connecting via HTTPS, it pops up a dialog that says "The server
  requested a certificate. Please select one of these certificates or
  press [Cancel] to send none" and then requests the master password.
- IE: Does not use SPKAC, but has a similar mechanism using the XEnroll
  control. With the default security settings, both requesting a certificate
  and installing one pop up confirmation dialogs explaining the situation
  and having a default of 'No'.
  Not that it does not have problems with certificates, though. Has anyone
  else ever noticed that if you have have more than a certain number of
  DNS subject alternative names, the certificate chain validation just
  breaks? This is actually a productive problem at $CUSTOMER, where they
  have a large webserver which has somewhere around 50 virtual hosts ...
- Safari: Does not say a peep during the SPKAC request generation. Allows
  for 512 bit keys, btw - whoever would want a 512 bit key these days?
  I could not find the correct MIME type to send the certificate for
  installation (I'd be interested to know though if anyone has an idea),
  but I'd assume the installation uses keychain (at least under Mac OS X,
  no idea what they do on Windows), which hopefully does some prompting.
- Konqueror: Pops up a 'KDE Certificate Request' wizard during SPKAC
  key generation which will ask for a password for the private key. I could
  not test this any further though, because my Konqueror installation
  did not create the request. Apparently, it sends 'deadbeef' though if
  it can now create correct SPKAC data ... :-) Allows for 512 bit keys, too.