149673 - Multiple prompts to re-select an SSL client certificate

Status: RESOLVED DUPLICATE of bug 431819

(Core :: Security: PSM, defect, P3)

Description

[bagee]

BuildID:    2002053012

I unfortunately don't have a public example of a server that shows this 
problem.  :(  I accidentally ran into it on a machine on an internal network 
and have since reproduced it on a few different client and server machines in 
the same environment.

This issue reproduces when you attempt to connect to a web server with SSL 
support, and the server is set to require every client to present a valid 
client certificate.  You need to have a client certificate loaded in Mozilla 
that the server will accept, and you also have to have Mozilla set to prompt 
you every time you need to present a certificate (the "Ask Every Time" option 
in the Client Certificate Selection dialog, which is not the default setting, 
it seems).

The problem behavior is that in this type of environment, you'll be able to 
connect to the server and start browsing content, but you'll often be prompted 
to select your client certificate again and again during the same session as 
you browse around.  This seems to be most easily reproduceable by requesting a 
page that has many tags with the 'src' attribute (I have a page with about 50 
<img> tags that I use for this).  It seems as though for many of the image 
requests in the page I get re-prompted to select my client cert.

This does not happen if you have Mozilla set to the "Select Automatically" 
option in the Client Certificate Selection dialog.  I'm assuming that the issue 
is still there in that case, but you never see the prompts since Moz is re-
presenting your certificate for you each time it needs to.

This does not reproduce in Netscape 4.7*, and the really odd thing is that this 
also does not reproduce if you select a profile created with Netscape 4.7* when 
you start Mozilla (in my environment my  NS 4.7 profile has the same client 
certs as my Moz 1.0-created profile).

While running Mozilla 1.0 with the 4.7-created profile, you simply won't see 
the repeated cert selection prompts, even while using the same browser 
configuration used to repro this with a Moz-created profile.

This issue seems to also be present in the linux Mozilla build ID 20020412, and 
also in Netscape 6.2.1 and 6.2.2 on NT4 and linux.

For my web server I've been using Apache/1.3.24 Ben-SSL/1.47 (Unix) on debian.  
I believe this will also reproduce if you're using a recent version of OpenSSL.

The client certs I've been using to repro this are in PKCS12 format.

Reproducible: Always
Steps to Reproduce:
1. Make sure that your web server is set to require the client to present a 
valid certificate (in my Apache/Ben-SSL config this entails 
setting "SSLVerifyClient 2" and pointing SSLCACertificateFile to a file with 
the cert of the CA who signed my client certs).
2. Start Mozilla and select a profile that was *not* converted from an old 
Netscape profile.  If necessary, you can just create a new profile with Mozilla 
to use to repro this.
3. Open your Mozilla preferences and go to 'Privacy & Security | 
Certificates'.  Select the "Ask Every Time" radio button in the Client 
Certificate Selection area.
4. Make sure that you have at least one valid client certificate imported.
5. Make sure that you can successfully establish a connection to your HTTPS 
server and successfully request some content.
6. Attempt to request a page with at least 5-10 images.

Actual Results:  When I request a secured page with multiple images, I usually 
get several prompts in a row to present my client cert again.

Expected Results:  It should prompt me to select a client cert at the beginning 
of the session, and should not pop up multiple cert-selection prompts when I 
visit a single page with many images during my session.


For users who only have/need one client certificate, then leaving Mozilla's 
Client Certificate Selection setting at "Select Automatically" is a valid 
workaround.

However, if a user has multiple certs, and one cert is intended to get access 
to resources which the other is not valid for, then that workaround could be 
problematic.  Mozilla might automatically select the wrong certificate when 
prompted (I think if you have multiple certificates, it selects which one to 
use based on the alphebetical order of the certs' CNs, but I'm not sure about 
that), which could result in the user not being able to access certain 
resources unless they switched their cert selection setting to "Ask Every 
Time".  And then once that was done they would probably run into the multiple-
prompt problem.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 2

[Stephane Saux]

Kai

Comment 3

[Kai Engert [:KaiE:]]

bagee: I assume in your example, where you are manually prompted again and
again, all of your referenced images are indeed accessible using the same
certificate to authenticate.

It sounds in your environment the browser is doing a SSL handshake very often. I
believe under normal circumstances, the SSL session cache would avoid doing that
too often.

I have set up a test site at https://www.kuix.de/misc/test38/
Because I also use my CA for some production purposes, I need to prepare some
certificates to give out, though, before you are able to access.


I am able to reproduce the effect. I am prompted at least twice. Even if I
minimize the delay caused by manually selecting a cert, by turning off security
warning, and making sure I'm already logged in to the security device.

If I confirm the second cert selection prompt quickly, that's it. But if I wait
a moment before I confirm the second cert selection prompt, I will see a third
prompt.

This behaviour does not seem to be dependent on cache or http pipelining settings.


It seems, after doing the first handshake with a SSL site requiring client
authentication, we will be doing at least one additional handshake.

Comment 4

[Guus Gerrits]

I had the same problem and found that this problem is somehow connected to the
caching of the MasterPassword.
In case no masterpassword has been set, Mozilla shows the described behaviour of
prompting to select your client certificate again and again during the same
session. In case the masterpassword has been set, Mozilla only asks once to
select the client-cert and then (as it tries to access the privatkey) asks the
Masterpassword. No further prompts after that.

Workaround: In case you did not set your masterpassword (which is for security
reasons not a good idea), set your masterpassword to a known short value (e.g.
initials or "123") and set the MasterPassword-Timeout to "The first time its
needed".

Comment 5

[Ken Johanson]

I have the same problem (or wouldnt have found this bug! :-), and can add that:

1) It also happens if the server wants optional client certs: (SSLVerifyClient
optional)
2) The symptom occurs after keep alive timeout (since thats when the client
would need to re-present its cert) -- so the experience will vary by webserver.
3) It doesn't happen on IE - after the keep alive times out, IE auto resends the
pre-selected cert, akin to HTTP authentication - what we're looking at this bug
for :-).
4) contrary to one suggestion, setting the master password does NOT eliminate
the problem (for me).

Here's a sample site to test with, with a trusted signer, optional client
verification, and small keep alive (30 seconds makes it easier to test).
https://up.ascentmedia.com

This bug is proving to be a real show stopper though - it makes the web app
almost unbearable since the cert dialog pops every 30 seconds.

Sidenote: we chose 30 seconds to reduce DOS risk, handle higher concurrent
connections, and because that's usually plenty to a client to select a cert.
HOWEVER the sample webserver has a bug where you have to pick you client cert
with 1-2 seconds and hit okay (it wants a near immediate client response for the
handshake - we're working on that)... Ironically IE deals with the delayed cert
confirmation, probably by rertying the connection if the first closed. IE 6
happens to work flawlessly all around...

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Ken wrote:

> 2) The symptom occurs after keep alive timeout (since thats when the client
> would need to re-present its cert) 

Not unless the server has a non-working SSL session cache.  
Normally an SSL client connects to a server, does a full RSA handshake 
including client authentication if requested.  The client and server negotiate
an SSL "session key" (a.k.a. master secret).  The next time the client connects
to the server, it reuses that session key.  If the server has also kept (cached)
that session key, the client and server can resume operations on the previous
session, without doing any RSA operations or using any certs.   

If your server is not restarting SSL sessions, and is doing full RSA handshakes
for every connection, THAT's the cause of the problem you're seeing.  

Comment 7

[Ken Johanson]

Nelson, if a users hits 'cancel' on the client cert selection dialog, should Moz
remember that decision, or would a recurring-select-cert effect be related to
the server not supporting SSL sessions across timeouts (e.g. the server should
cache null client cert sessions?)?

When I click cancel the dialog returns after connection timeouts, whereas I
might expect the browser to remember the decision on an application-session
basis (just as I might expect it to remember chosen certs).

I'm trying to fully qualify whether what I'm seeing is the server's fault -- or
if in fact my sample server (comment#5) (now has 300s keep alive) would make a
good test for fixing this actual bug report.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

As presently defined, Every time an SSL server asks the client to authenticate
with a certificate from a named CA, and the user has a cert that was issued,
directly or indirectly by that named CA, then mozilla should do one of the 
following:
a) automatically select a cert with which to reply, or
b) ask the user to choose a cert with which to reply from among those that 
the user has that were issued by any of the CAs listed by the server.
The user has a preference that tells mozilla which of those to do.

Then once the cert is selected, mozilla should do one of the following:
c) ask the user to enter his password for the private key, or 
d) if the user has previously entered his private key password in the last
N minutes, use the private key without asking him again.
Again, the user has a preference that tells mozilla which of these to do.

One could imagine an Enhancement Request for mozilla products, asking them
to have a UI that is similar to the UI the user sees when he has enabled
the form manager.  The UI would ask him to choose between
- Authenticate for this site now,
- Don't authenticate for this site, this one time,
- NEVER authenticate for this site.

That would be purely a matter of UI design and storage, and would not 
necessitate any changes to NSS.

So far I have not read anything here that suggests any flaw in mozilla
browsers.  Since you're developing a server, and it has known issues,
you can guess where I think the problem lies. 

Use ssltap.  Capture the traffic between client and server with SSLtap.
run ssltap on the same server box where your ssl server is running.
Use the command    ssltap -sxhlp proxyport localhost:serverport
where proxyport is the port to which your client will connect
and serverport is the port on which your server is running.

The output of ssltap will tell all.  Attach it to this bug, (as an attachment,
not as a comment), if you like.  

Comment 9

[Ken Johanson]

(In reply to comment #8)
> Then once the cert is selected, mozilla should do one of the following:
> c) ask the user to enter his password for the private key, or 
> d) if the user has previously entered his private key password in the last
> N minutes, use the private key without asking him again.

Nelson, this seems to be the problem with the Mozilla backend, then. - it *does*
ask him again (at least at the SSL session timeout), instead of remebering the
decision for the session duration, e.g. instead of behaving semanticly like a
http-session cookie, or http-authentication... being re-used during the session. 

This is a marked contrast to how IE behaves (and Safari and Konqueror also if
memory serves) - it automatically re-sends the chosen client cert for the
remainder of the session (the application's) duration. I'm not saying that this
is desirable behavior - one could imagine utilizing the SSL session-timeout
config on the server to control when a client would have to re-send their cert
(i.e effect a logout or change-user) -- but this seems moot since Mozilla and
other apps simply re-present the client-cert selection dialog (if the user
doesnt have a keystore timeout, then they're not really logged-out/safe anyway).

This is the essense of this bug. The subject could also be worded "Mozilla
prompts to re-select an SSL client certificate after SSL-session timeout"

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Ken,  Reread the first sentence of comment 8, carefully.

I think you have confused an SSL session (which is part of the SSL protocol)
with an https (keep-alive) connection duration.  The two are not the same. 
An SSL session does not end when an https connection ends.  It should be
reused in each successive https connection between the same browser and 
server for quite some time (up to a day). 

The fact that the user is being prompted over and over, with each new 
connection, as https keep alive times out, is indicative that the server 
is not restarting SSL sessions with new connections.  THAT is the problem.
The fact that the server requests client authentication over and over
instead of restarting SSL sessions is itself a defect, and not one in mozilla.

Again, mozilla is working as designed and intended.  You may wish to request
an "enhancement" (a change to the specification) for mozilla, to ask that it
behave as IE does (IE's behavior is not the definition of correct behavior),
and that request will be prioritized accordingly.  But from mozilla's 
perspective, the browser works great with servers that properly implement
SSL session restart, and "enhancing" to work with servers that apparently
do not, is not likely to be a high priority, IMO.

In any case, I'd recommend that no further action be taken on this bug until
a full ssltap output is attached.

Comment 11

[Ken Johanson]

(In reply to comment #10)
> Ken,  Reread the first sentence of comment 8, carefully.
> 
> I think you have confused an SSL session (which is part of the SSL protocol)
> with an https (keep-alive) connection duration.

Absolutely not, I understand the differentition fully. If you re-read my last
comment carefully, you'll see that I fully qualify "ssl session timeout causing
the cert prompt", which IS independent of whether the server correctly supports
ssl-sessions or not (in either case the cert-select dialog re-appears, in a
*fully* frivilous fashion in the case where the user has not asked for his
keystore to timeout). In other words, if a user walks-away from his machine and
a felon can walk up and click okay to a re-appearing cert dialog, it does not
good whatsoever. Again I say, *that* is the essense of this bug. 

I respectfully ask you to cite what spec it is that you're referencing, that
says this is intended behavior.

Comment 12

[Ken Johanson]

(In reply to comment #11)
Additionally:

1) High volume/user server operators frequently choose intentionally low ssl
session (and other session type) timeouts (a quick poll of some friends using
x509 client auth).
2) SSL sessions are not (from what I've seen) ever shared between servers in a
cluster, so anytime round-robin or othe load balancing come into play, Mozilla
will re-present the cert select dialog (when the clusters have the same server
certificate installed).

So in both cases the repeated cert-selection can be considered a hinderance to
the web application, and without benifit.

Comment 13

[Ken Johanson]

> In any case, I'd recommend that no further action be taken on this bug until
> a full ssltap output is attached.

Nelson, would you please consider rating this (at least by acknowledgment) as a
higher priority bug in consideration of the fact that small
SSLSessionCacheTimeout server config values will repeatedly prompt for
re-selection of client cert, as does also communication with round-robin or
other load balanced server farms (having identical server certs). And, that the
repeated cert-select dialog is frivilous if the user doesn't have a keystore
timeout, because:

a) Some mozilla browsers (Firefox at least) do not provide an explicit keystore
logout control, so the effect is that the certificate is available until the app
is closed, or the server session expires, whichever time is smaller.

b) For consistency, users expect two types of logout methods:
 1) close the application (browser) or desktop logout.
 2) in web based applcation, click the logout link. Having a 3rd concept of a
control that essentially applies only to client certs (eg access to the certs
priv key) increases chance for user mis-undertsanding and error. (For exmaple
the Moz suite's Password manager->Logout menu wrongly implies to laymen that
web-based logins will also have the same logout effect)
  2.a) I have found no commonly available server API that allows web-apps to
expire their server(s) ssl session caches for a given session. In other words
users have come to expect that logout only occurs after browser/dektop logout.

c) Consistency with other browser products - all other browser products that
I've tried *do* automcatlly re-send the client-certs for the duration after the
keystore has been opened, _until_ it is explictly closed (eg Desktop logout or
application-close, depending on product).

I urge you to treat this as a substantial bug because it is ***very*** obtrusive
to end users, especially when the SSLSessionCacheTimeout value is low (as is
typical *and* recommended) or when server load balancing is used.

Thank you.

Comment 14

[Alon Bar-Lev]

*** Bug 300375 has been marked as a duplicate of this bug. ***

Comment 15

[Alon Bar-Lev]

Hello,
Just wanted to know...
Is this going to be solved?
If yes, which version will it be merged?
It is VERY annoying... Almost every refresh I need to reselect my certificate...

Comment 16

[Scott Gifford]

*** Bug 313908 has been marked as a duplicate of this bug. ***

Comment 20

[Kai Engert [:KaiE:]]

related: bug 431819

Comment 21

[Peter Binney]

I agree with Alon Bar-Lev
This has been an extremely long-lived bug and continues to make FF unusable to those of us with multiple certs.
When oh when will it be fixed??

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

I wonder if any of the people who are desiring a browser change to solve
this problem have EVER complained to the makers of the broken servers 
upon which they depend, asking the makers of those servers to fix their
SSL session caches.  

How about it?

I recently learned in correspondence an Apache developer that neither OpenSSL
nor the Apache plugin mod_ssl ever cache client certs along with their SSL
sessions.  This causes to all too common phenomenon of a server that requests
a new client authentication on every connection.  The alternative to mod_ssl 
known as "Apache SSL" DOES cache client certs along with SSL sessions, and so
it does NOT have this problem of constantly requesting client certs.  

Perhaps the server products that have this problem should consider switching
from mod_ssl to Apache_ssl.  THat might cause their servers to behave 
reasonably with respect to ability to resume client authenticated SSL 
sessions without needing to request client authentication again.

Comment 23

[Eddy Nigg (StartCom)]

Errr...that would be some 45% of all SSL enabled web servers according to Netcraft.

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

Eddy, nowhere near 45% of servers use client auth.  probably not even 4%.

Comment 25

[Eddy Nigg (StartCom)]

That's correct too.

Comment 26

[Kaspar]

(In reply to comment #22)
> I recently learned in correspondence an Apache developer that neither OpenSSL
> nor the Apache plugin mod_ssl ever cache client certs along with their SSL
> sessions.

Are you referring to this message?

  http://www.imc.org/ietf-tls/mail-archive/msg08691.html

As Ben indicates, he's "not sure if this has been fixed". In the meantime, it has, of course. mod_ssl is storing complete OpenSSL session info in the cache (which also includes the peer cert).

> Perhaps the server products that have this problem should consider switching
> from mod_ssl to Apache_ssl.  THat might cause their servers to behave 
> reasonably with respect to ability to resume client authenticated SSL 
> sessions without needing to request client authentication again.

That's nonsense, sorry. A session cache has always been available in mod_ssl - properly configuring that is completely sufficient (cf. http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsessioncache; use shm [recommended], not dbm, as the latter has a limit of 950 bytes per session, which is sometimes too small to hold the peer cert). The default for mod_ssl is "SSLSessionCache none", which is by far the most likely explanation for "misconfigured servers".

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

Kaspar,  Yes, that's the message.  If the problem is fixed in mod_ssl,
that's good to hear.  Nevertheless, there are many individuals who 
continue to report that the servers they have setup continue to request
SSL client authentication on EVERY connection, despite them having 
followed the directions to enable a server SSL session cache.  

It is apparently common for them to conclude that the client is as fault
and beat the drum for client changes, when clearly, if the server was 
working right, it would not request client auth on EVERY connection.  

I'm just reminding them that they can beat the drum in the direction of the
sources of their server products, as well as in the client's direction.

Comment 28

[Alon Bar-Lev]

Hello,

I don't like the direction of the discussion.

The discussion is regarding *USER EXPERIENCE* and not technical experience.

A user does not expect to select his certificate again once he selected it once for a target server, exactly as he does not expect to enter his user/password again and again.

The SSL session cache is *CACHE* it can be dropped from whatever reason at the client or server side. And may be created if the client needs more sessions (such as file transfer or AJAX).

The web client application should remember that the user already selected credentials (may be client certificate, user and password or any) for target server, and reuse them even if the session is reestablished (it can be socket, SSL cached or SSL new).

The fact that the user should be bothered because of a technical limitation of the protocol is unacceptable.

I am sure that it is not that hard to fix this so using smartcards with firefox may actually be usable.

Alon.

Comment 29

[Eddy Nigg (StartCom)]

Kaspar, I'm not sure about that...I've got an Apache/2.2.3 with settings similar to

SSLSessionCache         shmcb:/some/path/mod_ssl/scache(512000)
SSLSessionCacheTimeout  3600

But I'm still required to handle the session state otherwise in order not be re-prompted. Basically if I invalidate the session at the application level, Apache will ask once again for the certificate - indicating to me that there is no session for the cert. I don't know and don't really care who's fault this is, but those are the facts since ever I implement client cert auth.

Here some example status:

SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current sessions: 116
sub-caches: 32, indexes per sub-cache: 133
time left on oldest entries' SSL sessions: avg: 830 seconds, (range: 93...3312)
index usage: 2%, cache usage: 6%
total sessions stored since starting: 538
total sessions expired since starting: 422
total (pre-expiry) sessions scrolled out of the cache: 0
total retrieves since starting: 5028 hit, 26 miss
total removes since starting: 0 hit, 0 miss

Comment 30

[Kaspar]

(In reply to comment #27)
> I'm just reminding them that they can beat the drum in the direction of the
> sources of their server products, as well as in the client's direction.

Fine, nothing wrong with that, Nelson. But ill-advising people to switch to Apache-SSL based on some FUD about mod_ssl and its alleged session caching deficiencies (as you did in comment 22) isn't helpful in this situation.

(In reply to comment #28)
> The web client application should remember that the user already selected
> credentials (may be client certificate, user and password or any) for target
> server, and reuse them even if the session is reestablished (it can be socket,
> SSL cached or SSL new).
> 
> The fact that the user should be bothered because of a technical limitation of
> the protocol is unacceptable.

Fully agreed, Alon. See also bug 159274, and https://wiki.mozilla.org/PSM:CertPrompt.

(In reply to comment #29)
> But I'm still required to handle the session state otherwise in order not be
> re-prompted. Basically if I invalidate the session at the application level,
> Apache will ask once again for the certificate

I'm not sure what session you're referring to here. In the stock version of mod_ssl, there's no option to "invalidate the [SSL] session at the application level", to the best of my knowledge.

SSL session caching with mod_ssl configured to "SSLVerifyClient require" works fine for me - just make sure that no SSL renegotiations come into play (e.g., with per-directory settings). OpenSSL will disallow a session resumption in that case (and enforce a full handshake), due to the SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION option being set by mod_ssl.

Comment 31

[Eddy Nigg (StartCom)]

I handle sessions in the application level instead of mod_ssl once authenticated successfully. However I have other sites (mainly testing) where I still can reproduce repeated prompting of client cert.

Not sure what you meant with "per-directory settings". It's a typical use case to require for example /admin/ and everything in that directory to authenticate with a cert.

Which browser are you using and what are your settings?

Comment 32

[Kaspar]

(In reply to comment #31)
> I handle sessions in the application level instead of mod_ssl once
> authenticated successfully.

Which means that only the first SSL connection is really mutually authenticated, I assume. Doesn't strike me as a particularly secure approach.

> Not sure what you meant with "per-directory settings". 

See http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context. I don't think this bug is the right place for discussing mod_ssl configuration questions.

> It's a typical use case to require for example /admin/ and everything
> in that directory to authenticate with a cert.

This will always trigger a renegotiation, unless the same settings for SSLVerifyClient and SSLVerifyDepth are in effect at the virtual host level. You're running into the situation I described in comment 30.

> Which browser are you using and what are your settings?

Firefox 2, in that case, with security.default_personal_cert = "Ask Every Time".

Comment 33

[Eddy Nigg (StartCom)]

(In reply to comment #32)
> Which means that only the first SSL connection is really mutually
> authenticated, I assume. Doesn't strike me as a particularly secure approach.

Can't see any deficiency with this approach, except if session handling should be broken. Basically, that's what I'd expect SSL caching would do instead.

> See http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context.

Yes, the directory directive.

> I don't
> think this bug is the right place for discussing mod_ssl configuration
> questions.

Actually it is, since somehow client certificate authentication seems to be broken and I'm not the only one facing it. Getting this sorted out would be a relieve for many.

> This will always trigger a renegotiation, unless the same settings for
> SSLVerifyClient and SSLVerifyDepth are in effect at the virtual host level.

Yes, obviously those are set on the virtualhost level within the directory directive.

> You're running into the situation I described in comment 30.

Which one? Setting client auth for the entire host doesn't make sense to me! This wouldn't be a typical use case. 

Nevertheless here some configuration example. I'd be glad if you could point me to the mistake:

	<Directory /path/to/some/dir>
		SSLCACertificatePath /path/to/client-auth-certificates/
		SSLVerifyClient require
		SSLVerifyDepth  2
		SSLRequireSSL
		SSLOptions +StdEnvVars
	</Directory>

Anything in directory /path/to/some/dir and sub directories should prompt for client auth - ONCE. It shouldn't prompt again until the session expires. If mod_ssl can't do that I'd claim this to be a bug. (Other authentication forms seem to work perfectly this way and Apache doesn't request re-authentication).

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 30
>> The fact that the user should be bothered because of a technical limitation 
>> of the protocol is unacceptable.
>
> Fully agreed, Alon. 

Of course, it's not a limitation of the protocol.  It's a limitation of some
some flawed server implementations (I'm including "configuration" in the 
meaning of "implementation" there).  

So, this statement seems  to be saying: "the user should not be bothered 
because the server's are flawed."  Sorry, I don't agree with that in any way.
Correct operation and benefit of ALL protocols requires that both ends 
correctly participate.  I do not accept that the client is responsible for 
all flaws, including those in the server.  When the server is flawed, it 
must be fixed.  The (apparent) fact that many server admins don't know enough 
to recognize that the flaw is in the server doesn't change that fact.

Comment 35

[Alon Bar-Lev]

(In reply to comment #34)
> In reply to comment 30
> >> The fact that the user should be bothered because of a technical limitation 
> >> of the protocol is unacceptable.
> >
> > Fully agreed, Alon. 
> 
> Of course, it's not a limitation of the protocol.  It's a limitation of some
> some flawed server implementations (I'm including "configuration" in the 
> meaning of "implementation" there).  
> 
> So, this statement seems  to be saying: "the user should not be bothered 
> because the server's are flawed."  Sorry, I don't agree with that in any way.
> Correct operation and benefit of ALL protocols requires that both ends 
> correctly participate.  I do not accept that the client is responsible for 
> all flaws, including those in the server.  When the server is flawed, it 
> must be fixed.  The (apparent) fact that many server admins don't know enough 
> to recognize that the flaw is in the server doesn't change that fact.

The cache can be dropped by either side any time due to resource limit or timeout.
This is what cache is for, nobody thought about the end user when designing this cache. It has three reasons: Reduce the time to reestablish session (less bytes), reduce CPU power resulting in asym-crypto, less frequent certificate validation.

Anyway, what you call flaw implementations just demonstrate the broken user experience in Firefox.

Comment 36

[Daniel Veditz [:dveditz]]

UI for permanently remembering per-site cert selection is bug 395399.
Remembering selection for the browser session is bug 453802 which might be a dupe of this but is currently less bogged down in technical discussion.

Comment 37

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 39

[musiquegraeme]

Another aspect of this bug:
If there are two or more certs and the wrong one is chosen then connection fails and TB doesn't try the other one. The only way around this is to set, "Ask me each time"... Could the choice be made to look at each possible certs?

Comment 40

[musiquegraeme]

Over night I had the thought - what is the privacy problem with this. To have private certs added to my cert.db takes a lot of effort - I have to know the password and I can only do this entry manually. So if I added a cert why will FF not trust it... Are you taking over? Certs that I have added should be trusted and therefore Select Automatically should select correctly, look at the certs I have and choose the one that works - I trust them all after all.
At the moment Select Automatically is BROKEN and takes the first one in the list, unlike its behaviour in the past.
Please fix it.

Comment 41

[musiquegraeme]

Why is the comment I made yesterday - Comment 39 saying that it was made two years ago???