SSL Certs Cached By Browsers, Privacy Issues?

[neverrubanothermansrhubarb@xxxxxxxxxxx]

Aside from the much discussed forged SSL certificates, and the most recent
mention of uptime being passed via SSL, I now bring up a new discussion
regarding legit SSL certificates, how they may be stored/cached and any
possible privacy implications of this.

Are there any privacy considerations when it comes to your browser, Tor,
and SSL? The subject was brought up on #tor @ irc.oftc.net the other day,
with a brief log pasted to the bottom of this post for reference. It was
observed, in Konqueror (Settings->Configure Konqueror->Crypto->Peer SSL
Certificates-> and click on one cert to see cache options) peer certs may
be cached and they may expire or be retained forever, are there privacy
implications to either choice, or to the caching of these certs in
particular?

Specific questions for those of you who know anything about SSL:

+ How do different browsers (Firefox, Epiphany, Konqueror, etc.) cache SSL
certificates?
+ If the cache method differs, to what degree? Is any method between them
more dangerous to privacy when using Tor or not?
+ Should cached SSL certs be purged from the browser between sessions?
+ What about SSL2?

Any tests, thoughts, discussions on this topic welcome here on the list!

**************************************
* BEGINNING OF CHAT LOG FOR REFERENCE:
**************************************
<madgorilla> Two questions: [1] When you accept an SSL cert from a website
does retaining it until it expires affect privacy, esp when I read an
uptime ssl bug with ff recently, should these be purged after each browser
session [2] may tor hidden services use SSL stacked on top?
<nickm> 2 is easy: yes.
<madgorilla> ty
<nickm> 1 depends on browser behavior and what you mean by accept.
<madgorilla> reading on the tor list someone mentioned uptime being
transmitted through SSL with FF, perhaps not a bug but a feature? :P
<madgorilla> and by mean accept I mean cache peer ssl cert until they expire
<nickm> I don't see what the uptime problem has to do with retaining ssl
certs.
<madgorilla> okay, let us ignore the uptime issue and focus on retaining
ssl certs then for the sake of this question please :)
<madgorilla> should these be purged between browsing sessions or retained
<madgorilla> some say they are valid for years
<nickm> okay.  so I could be wrong about this, not being as deep in ssl as
I'd like, but my understanding is that whenever you connect to an ssl
server for a new session, the server sends you a certficiate.  Every time.
 Does the browser really cache it?  Or are you talking about clicking
"yes" to the "accept this cert forever" button?
<madgorilla> nickm, konqueror appears to cache them
<nickm> I guess the browser could verify it only once, so it doesn't have
to do the extra public key operation every time.
<madgorilla> it even gives you the option to cache them forever
<madgorilla> so how does firefox handle this and between the two, is there
a risk
<madgorilla> perhaps I could pose this Q to the list
<madgorilla> or another one SSL related if such a ML exists
<madgorilla> in konqueror: Settings->Configure Konqueror->Crypto->Peer SSL
Certificates-> and click on one to see cache expiration status and whether
you want to retain it forever
<nickm> To be clear, are you talking about certs you manually approve, or
ones the browser accepts without your help.
<madgorilla> I don't know how FF deals with them
<madgorilla> In konqueror these are accepted unless they are bad
<madgorilla> if they are bad it pops up with a warning and choices
<nickm> Assuming by bad you mean not signed by a recognized CA, sure.
<madgorilla> yes, sorry for any lack of clarity there.
<nickm> So are you talking about certs that it asks you about, or all certs?
<weasel> however,
<weasel> when the cert is self signed or otherwise not automatically
accepted by a browser and you say
<weasel> "accept this cert now and forever" then next time you go there
the site will be able to tell that you've been here before
<nickm> right.
<weasel> simply because you finish your ssl handshake faster
<killerchicken> That is a very interesting topic
<killerchicken> it seems that indeed a server can tell whether someone has
already been to the site, even if they have a certificate signed by a
trusted CA
<weasel> other than session caching?
<killerchicken> hm, I just had a very quick look at the RFC
<nickm> Of course, if most users click "accept now and forever" and you
don't, then you stick out a lot.
<killerchicken> no, that's not it
<killerchicken> it seems that clients could cache information about the
master key
<killerchicken> I don't know whether that is only session caching or lives
for a longer time
<killerchicken> mikeperry: ping
<killerchicken> mikeperry: earlier, there was a discussion about ssl
certificates
<killerchicken> maybe you're interested
<mikeperry> the one on or-talk?
<killerchicken> no, in this channel
<killerchicken> it was about whether a server could note that a client has
been to the site before
<killerchicken> By looking at how long it takes for the client to accept
the cert, or possibly by not having to send a cert at all
<mikeperry> we're talking about trusted CA signed certs? or certs the user
installs?
<killerchicken> both
<killerchicken> I think the latter is always easy
<killerchicken> but is it possible that a client caches the cert even for
trusted CA certs?
<mikeperry> according to my wireshark, the server cert is always being
transmitted for each new tls connection
<killerchicken> good
<killerchicken> that was what we were wondering about
<killerchicken> I wasn't sure I understood the RFC correctly
<keb> what about ssl2

**********************
* END OF CHAT LOG
**********************