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

pgut001@cs.auckland.ac.nz (Peter Gutmann) writes:

> 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@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?

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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls