Re: [TLS] Verifying X.509 Certificate Chains out of order
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Verifying X.509 Certificate Chains out of order
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:
>
> 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=qwertyuiop at hotmail.com. 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?
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
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.