Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Oct 2008 19:18:20 +1300

I have a followup question for the topic of client-auth UI issues: In my
initial response I made the standard geek mistake of leaping in to address the
technical problem ("ah, I see your problem, you need to oil the guillotine and
then the blade won't stick any more") without examining the underlying
assumptions that it was based on.  The OP said:

  For browsers, there arose a concern that automatic and silent client cert
  authentication allows a web site to request cert authentication even when
  the user has no business relationship with the site, and could be used for
  user tracking, defeating anonymity of browsing.  So the default setting in
  browsers was changed to manual selection to avoid silent user tracking.

So the tradeoff made was to significantly negatively impact usability in
exchange for addressing a perceived privacy threat, specifically the fact that
if I connect to a site that (for some reason) decides that it doesn't want to
use traditional browser cookies or cache cookies or web bugs or Flash cookies
or a million other ways of tracking users (including SSL session cache
identifiers in the specific case of SSL) then they can now find out that I'm
/C=US/O=Verisign/OU=Class 1 CA/OU=No liability accepted/CN=The Jolly Green
Giant/email=[email-masked].  Maybe I'm missing something here, but
this seems to be a case of doing something that significantly negatively
affects security usability (and therefore actual real security) in order to
address an imaginary issue that only a geek could dream up.  Is there some
other issue here that I'm missing?

Peter.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Oct 2008 08:41:55 +0200

> other issue here that I'm missing?

Well, as a geek, I can dream up other issues: probing clients which bank
they are using, for those banks that use client-TLS, or other similar
probing.  Just add many https link for small images on your site to
https server that send the bank's CA that you are interested in as a
trusted root, and watch clients send back their end-entity bank
certificate.

However, I believe highly in usability, and don't think the privacy
attack above even comes close to warrant a poor user interface.

If someone really wants to solve this privacy problem, add a certificate
extension that tells browsers to never announce a particular end-entity
certificate except to particular hosts, and make browsers support it.  I
suspect you'll have trouble convincing everyone to implement the
feature, and the IETF to standardize it, because people will question
whether the privacy problem is a serious problem.

/Simon

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Oct 2008 20:00:41 +1300

Simon Josefsson <[email-masked]> writes:

>certificate except to particular hosts, and make browsers support it.

This probably needs to go to a list like hcisec to get HCI peoples' input, but
what about treating it like cookies, if people are concerned about privacy and
turn off cookies (which, if you include session cookies, may well make most of
the web unusable, but that's their decision) then your UI would pop up a
dialog before handing over the cert, otherwise keep the existing behaviour of
silently sending the cert.  If the concern is user tracking then give cert-
usage the same user interaction as cookie-usage.  The browser already has the
UI and whatnot there and users are, well, at least somewhat educated about
cookies, so just extend the existing mechanism to cover new cookie-equivalents
(including things like Flash cookies and the other odds and ends I mentioned,
which currently aren't handled well at all).

>I suspect you'll have trouble convincing everyone to implement the feature,
>and the IETF to standardize it, because people will question whether the
>privacy problem is a serious problem.

PKIX (the WG responsible for this) will standardise anything with an ASN.1 
syntax (there's an RFC for adding theme music to certificates, for example), I 
doubt you'll have any problems there :-).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Oct 2008 11:17:27 +0200

> other issue here that I'm missing?

There was a discussion on the PKIX list just a few days ago about what  
certificates are all about and what should go in them (yes, it's about  
time we've finally decided what certificates are all about)

Anyway, other than your DN a lot of other things can go in a cert. A  
certificate issued by Verisign is not very interesting, but a  
certificate issued by a bank or an employer may reveal your place of  
employment and some organizational structure. The Brazilian  
government, for example, includes the whole "chain of command" from  
the employee to the ministry for which they work. There is a privacy  
issue to sending all that information to a random SSL-enabled web  
server, and that is only the DN.  So you're not just "The Jolly Green  
Giant", you're the jolly green giant that works for the department of  
purchasing in the office of water works in the public works section of  
the ministry for national infrastructure (I'm making this up)

Other fields in the certificate can hold more interesting information:
- memberFrom - though PKIX actually rejected this, this field could  
say how long you've worked there
- clearance - that's what triggered the discussion on PKIX - so now  
you're the jolly green giant with "Top Secret" clearance
- mpeg of cat - now any random SSL server can know what your cat looks  
like.

I think one way of solving the silent tracking problem is to add a  
"presenting constraints" option to certificates that will instruct the  
browser to show the certificate only to servers and DNS addresses  
matched by a pattern, for example my bank can issue me a cert with  
PRESENTING_CONSTRAINTS=*.bankleumi.co.il so that only its own servers  
get this cert (when browsers support it in 10 years)

But I don't think selecting a certificate to present from a list  
(especially if the list has a "never present a certificate to this  
website" option) is all that onerous for a user.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Oct 2008 22:39:00 +1300

Yoav Nir <[email-masked]> writes:

>browser to show the certificate only to servers and DNS addresses matched by
>a pattern, for example my bank can issue me a cert with
>PRESENTING_CONSTRAINTS= *.bankleumi.co.il so that only its own servers get
>this cert (when browsers support it in 10 years)

The problem with this is that every time you want to use your cert at a new 
site you need to get the cert re-issued with updated constraints.  What you 
really want here is an attribute certificate, which is a good match for this 
sort of thing.  However in this case an even better match (not helped by the 
fact that attribute certs were basically stillborn) is to use something 
SAML-based (or insert your favourite SAML-equivalent system here) to hand over 
only the bits you want.  Unfortunately you then get to deal with the 
complexity of managing all this, which is still an active and ongoing research 
topic...

Peter.

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 16 Oct 2008 12:59:44 -0700

Peter Gutmann wrote, On 2008-10-15 23:18:
> I have a followup question for the topic of client-auth UI issues: [...]

> The OP said:

One major difference between tracking with cookies (or TLS session IDs) and
using certs is that cookies and TLS session IDs contain only information
previously put there by the server itself.  When the server fetches them,
it doesn't learn anything about the user that it didn't already know.
It has merely learned that a user who has previously been to this web site
has now returned.  But certs reveal information that could well have
previously been unknown to the server.  Fetching certs is a way to do
information discovery.

As for this being a significant negative usability impact, soon the browser
will be able to remember a user's choices about certs for servers, including
the choice of "send no cert", and thereafter, the browser will no longer
bother him to repeat a choice he has already made. So, the impact will
typically be at most one choice per site. There will be no negative
usability impact for servers to whom the user really wants to authenticate.
A user won't mind choosing a cert for authenticating to his bank.  He will
mind being asked to choose while browsing porn. :)

Finally, I will add that the decision to change the default behavior for
client auth was made by the browser UI folks, not by the crypto folks.
The folks who made this decision are the UI czars who make the big
decisions about the trade off of usability vs other things (such as
security). They apparently thought the threat of this form of tracking
was serious enough to warrant the change.  The subsequent discovery of
lots of sites that are doing this seems to prove that the threat was not
merely imaginary.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Oct 2008 03:56:59 +1300

Nelson B Bolyard <[email-masked]> writes:

>previously put there by the server itself.  When the server fetches them, it
>doesn't learn anything about the user that it didn't already know. It has
>merely learned that a user who has previously been to this web site has now
>returned.  But certs reveal information that could well have previously been
>unknown to the server.  Fetching certs is a way to do information discovery.

I'm sure this can be argued endlessly, but given a mechanism that has 100%
coverage/penetration (cookies/Flash cookies/cache cookies/Javascript/whatever)
and one that has a coverage level two orders of magnitude below the margin of
error, I know which one I'd be using to track users, regardless of some
theoretical advantage that one might have.

>client auth was made by the browser UI folks, not by the crypto folks.

UI folks did this?  Wow.  I guess they had no idea of the consequences of
their actions :-).

>The subsequent discovery of lots of sites that are doing this seems to prove
>that the threat was not merely imaginary.

That doesn't say anything about the threat, merely that there are lots of
misconfigured servers.  The fact that the server admins had no idea their
servers were doing this and even less idea how to turn it off, and that the
servers threw the certs away when they were given them, would argue strongly
against any attempt at deliberate user tracking.

Peter.

---

From: Alexander Klink <[email-masked]>
Date: Tue, 21 Oct 2008 17:27:50 +0200

> theoretical advantage that one might have.

The practical advantage here was that the coverage level did not matter
- if you wanted to track users across two unrelated domains, you could
do so using TLS client certificates no matter if the users actually had
them (they were (nearly) unnoticeable to install) ...

> misconfigured servers.  The fact that the server admins had no idea their

I'd agree with that, I doubt that someone was actually using that as an
attack vector ...

Cheers,
  Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    [email-masked]
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls