full-disclosure - Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 10 Sep 2007 03:32:24 +0200
From: niclas <lists@...enritter.de>
To: full-disclosure@...ts.grok.org.uk
Cc: dev-security@...ts.mozilla.org, dev-tech-crypto@...ts.mozilla.org
Subject: Re: Firefox 2.0.x: tracking unsuspecting users
 using	TLS client certificates

> ... 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.

this is not new. in a way it has been in the apache
documentation for years. it simple, and it's very bad:

a) firefox does not ask the user which certificate to deliver if not set
up to do so.

b) firefox does not offer a checkbox to remember the choice the user
made. the irritating dialogue will appear up to two times for each
webpage and not stay activated for long.

(konqueror in comparison does remember the user's choice for each
domain/site. k. doesn't send out certficates without being told to.)

c) in the apache documentation you can read about a simple setupwhich
asks for and accepts ANY certificate that the browser delivers - which
leaves the choice to the browser and makes it deliver one _silently_ if
present.

(IIRC the choice is usually made by comparing certain fields in the
certificate, e.g. company, common name etc. the certficate that matches
best will be sent.
though the server certificate's CN must be * or match the domain to be
accepted, FF does not require any information from the client
certificate to match the domain it is sent to.)

you want to make use of that? very simple:

1) all information from the client certificate can of course be read by
the server, e.g. in a CGI.

2) though you could achieve this easily (contrary to statements on the
list my FF never required client certificates to be signed by a known
CA - why should it?), you do not have to make users actually install a
certificate. would be too obvoius anyway, and...

...users who are part of a company network or any other organization
which uses certificate authentication will already have one.

they are very concerned about security, so they are probably more
interesting targets anyway.

3) for tracking purposes just remember the fingerprint of ANY delivered
client certificate. combine it with any other information information
you get from the now perfectly identified client, like IP-address,
information filled into forms, etc.

4a) simple tracking of a certficate holder might be nice for secret
services and adserver owners, but as companies like to have their own CA
or at least write the company name into the certificates, competitors
can see easily who's clicking.

4b) if you are a spammer the valid e-mail-address stored in the
certificate might be of some value.

4c) the "common name" field is great information for phishers and all
kinds of evildoers who are now empowered to create individualized mails
with this information.

n.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/