If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

server certificates held for browser process lifetime

RESOLVED INCOMPLETE

Status

()

Core
Security: PSM
RESOLVED INCOMPLETE
12 years ago
10 years ago

People

(Reporter: NGUYEN Thanh lam, Assigned: kaie)

Tracking

Trunk
Sun
Solaris
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4

When you enter site with an unknown certificat authority you are presented with
a dialog box asking you to accept it permanently, temporarely or never. If you
accept it permanently, you have the possibility to remove it using the advanced
menu in the preferences. When you accept it temporarely, there is no way to get
rid of it unless you quit to the app (mozilla or firefox) and restart the app.
The intranet we are using is in development and the certificat is recreated as
soon as the intranet is restarted (can be up to 7 times a day).


Reproducible: Always

Steps to Reproduce:
cf details
Actual Results:  
Have to quit the app which close all windows. And restart the app.

Expected Results:  
2 possibilities:
1) have  in Preferences/Advanced/Managed Certificats... a menu displaying all
temporary certificat with the buttons to remove them like the permanently one.
2) when all tabs/pages pointing to that site is closed the certificat is removed.
Summary: temporary certificat still there → temporary certificate still there
This is a core PSM bug.  It is common to seamonkey and FireFox. 
I suspect this is a dup of bug 285440.  That is, I think that the 
fix for bug 285440 would also resolve this bug.

I has appeared to me for some time now that PSM holds on to, or leaks,
cert references that it receives from SSL.  Consequently, once the browser
sees a cert, it doesn't forget that cert for the remainder of the process 
lifetime.  I have been told that this is intentional!

I hope that PSM doesn't actualy leak these references, but instead adds 
them to some list from which they can be later freed when appropiate.  
That would seem to be prerequisite to bug 285440 also.  

In any case, I agree that there needs to be a way to tell browsers to 
reset all their crypto state and start afresh, without restarting the 
process.  This is also needed for switching profiles.  I wonder if 
profile switching works, or is broken.  If cert references are being 
leaked, then profile switching is certainly broken.
Assignee: dveditz → kaie
Component: Security → Security: PSM
Product: Mozilla Application Suite → Core
QA Contact: seamonkey
Summary: temporary certificate still there → server certificates held for browser process lifetime
Version: unspecified → Trunk
(Assignee)

Comment 2

12 years ago
Nelson, before talking about this bug, let me first talk about your concerns.


PSM tries to remember some CA certificates for the rest of the process session.
In PSM's AuthCertificateCallback a comment says:
  // We want to remember the CA certs in the temp db, so that the application
can find the
  // complete chain at any time it might need it.
  // But we keep only those CA certs in the temp db, that we didn't already know.

However, that code explicitly checks for server certs and will not remember them.

In addition, the list I just mentioned is a smart list.

PSM keeps all remembered certificates in an application list.
Before shutting down NSS, all remembered certificates are destroyed.
This was done to allow profile switching to work.
I would like to assume at the moment that profile switching still works, because
I have not seen any bug reports.


Now back to the "server certificates held for browser process lifetime" issue
discussed under this bug number.


I looked up, how PSM implements the permanent or temporary server certificate
storage. I did not implement it. In the "remember temporarily" case, the
keepSession value is set to TRUE.

If you think this implementation is bad, maybe you want to suggest an
alternative sequence of NSS calls to achieve the same thing?

However, if you think the code is fine in general, we could of course remember
the cert in a new list within PSM and clear that list when requested by the
user. But how would we do that? I guess we would make a copy on adding, and when
the time has come to destroy, we'd set keepSession back to FALSE and destroy our
copy?


static nsresult
addCertToDB(CERTCertificate *peerCert, PRInt16 addType)
{
  CERTCertTrust trust;
  SECStatus rv;
  nsresult retVal = NS_ERROR_FAILURE;
  char *nickname;
  
  switch (addType) {
    case nsIBadCertListener::ADD_TRUSTED_PERMANENTLY:
      nickname = nsNSSCertificate::defaultServerNickname(peerCert);
      if (nsnull == nickname)
        break;
      memset((void*)&trust, 0, sizeof(trust));
      rv = CERT_DecodeTrustString(&trust, "P"); 
      if (rv != SECSuccess) {
        return NS_ERROR_FAILURE;
      }
      rv = CERT_AddTempCertToPerm(peerCert, nickname, &trust);
      if (rv == SECSuccess)
        retVal = NS_OK;
      PR_Free(nickname);
      break;

    case nsIBadCertListener::ADD_TRUSTED_FOR_SESSION:
      // XXX We need an API from NSS to do this so 
      //     that we don't have to access the fields 
      //     in the cert directly.
      peerCert->keepSession = PR_TRUE;
      CERTCertTrust *trustPtr;
      if (!peerCert->trust) {
        trustPtr = (CERTCertTrust*)PORT_ArenaZAlloc(peerCert->arena,
                                                    sizeof(CERTCertTrust));
        if (!trustPtr)
          break;

        peerCert->trust = trustPtr;
      } else {
        trustPtr = peerCert->trust;
      }
      rv = CERT_DecodeTrustString(trustPtr, "P");
      if (rv != SECSuccess)
        break;

      retVal = NS_OK;      
      break;
    default:
      PR_ASSERT(!"Invalid value for addType passed to addCertDB");
      break;
  }
  return retVal;
}
When I wrote comment 1 above, I was confusing two separate issues.  My bad.
I was complaining that PSM remembers all SSL *CA* certificates that it 
sees, and remembers them for the lifetime of the process.  I believe 
that is a bug, and is the cause of many other bugzilla bug reports.  But that 
is not the subject of this bug, and I was mistaken in conflating the two.  

This bug complains that there is no way to get mozilla to forget an SSL 
server cert that the user has previously told it to remember and trust
for the process lifetime, other than restarting the process. 
That is, of course, working as designed.

I'm not sure what, if any, real problem that creates for users of legitimate
X.509 conforming server certificates.  It's quite OK for servers to change 
their certs many times a day, even if the certs are trusted explicitly in the
browser.

On second analysis, I suspect that these new server certs have been created
with the same issuer name AND serial number, every time.  Of course, that is
invalid.  If it is indeed the case that this server cert is being regenerated
with the same issuer name and serial number, then this bug is invalid.  

The solution is for each new server cert to be issued with a new serial number. 
That conforms to the X.509 rules and solves all problems of this sort.  

Sorry for the previous mis-analysis.

Comment 4

12 years ago
Nelson,

FYI, the CRL cache keeps a reference to CA certs whenever CERT_VerifyCert* is
used and requests a CRL check of a cert, even if there is no CRL - it keeps an
empty cache entry in this case, but keeps the CA cert in case there is a CRL
available later, in order to be able to verify it. That causes references for
all the CA certs to be kept throughout the life of a process. These CA cert
references can only be freed in ShutdownCRLCache, called from NSS_Shutdown() .
FYI, this behavior has been the case since 3.6 when the CRL cache was introduced .
(Assignee)

Updated

12 years ago
Whiteboard: [kerh-ehz]
QA Contact: psm

Comment 5

10 years ago
Does this still happen with the latest Firefox builds?

If not, please close the bug as WORKSFORME.

Thanks.
Whiteboard: [kerh-ehz] → [kerh-ehz], CLOSEME 08/20, DUPEME?
Due to lack of reporter feedback and the inability to reproduce this bug, it is being resolved as INCOMPLETE.  Reporter, feel free to reopen this bug if you still are experiencing this issue and wish to provide us with more information so that we can help.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [kerh-ehz], CLOSEME 08/20, DUPEME?
You need to log in before you can comment on or make changes to this bug.