163900 - Receiving a particular signed message permanently breaks trust in profile

Status: VERIFIED WORKSFORME

(MailNews Core :: Security: S/MIME, defect, P1)

Description

[Kai Engert (:KaiE:)]

I received a signed message from Ramin who produced that message using Outlook.

After I have read that message once, the trust settings in my cert database seem
to be corrupted, since previously valid signatures in other messages now show up
as invalid. This corruption is permanent, an application restart does not help.

Actual behaviour: Corruption, with no visible hint in cert manager

Expected behaviour: Reading a message should corrupt database.


I talked to Bob, he suspects, since we are importing all certs on receiving a
S/Mime message, one of those certs might have an identical subject and cause
something to be overwritten.


I will attach the message to this bug. Since forwarding does not work, you
either need to manually copy that message to a mailbox in your local folders
(using an ascii editor), or let me know, and I can resend that message to you,
and it will appear to come from the original sender.


Charles and John were both able to reproduce.


Here are the steps required to reproduce the problem:
=====================================================
1) Prepare a profile by removing *.db
2) Start the profile.
3) Import a p12 file from our internal production CA, like your own personal cert.
4) Open mail and read any other signed message first, to make sure you you see a
valid signature icon. Make sure that message is signed from somebody using our
own intranet CA. Like a signed message from yourself to yourself.

If everything is well, it means the intermediate cert is now known and trusted.
You are now all set for seeing the bug.

5) RESTART the application completely.

6) Go to mail and find the message attached / resent message.
7) Click the message

You'll see an invalid signature.

8) Click any other message that you previously read and confirmed that it had a
good signature. The signature will now be shown as invalid.

From that point, all other message signed from the same CA are reported as
having an invalid signature, too.

Even restarting the application does not help. The trust in the cert db is now
damaged.

Comment 1

[Kai Engert (:KaiE:)]

Attachment: Killer message

Comment 2

[Kai Engert (:KaiE:)]

Attachment: Structured dump of killer message

Comment 3

[John Unruh]

What is unusual about opening this particular email is that you receive two
certs in Other People's certs from Ramin, both email signing, and both with
different serial numbers.

Comment 4

[Robert Relyea]

The thing that causes the real problem is the message has a CA cert that doesn't
look like a CA cert, and chains to a non-existant root. This CA cert has the
same subject as our GTE Cybertrust Root cert. If I use Certutil to delete the
GTE Cybertrust Root cert from the database everything starts working again.

I see a couple of things we need to solve:
1) why is NSS choosing this cert when doing chain processing (there are a couple
of strikes against it.... it's older, and it's not a CA cert). I'll post what I
find about this here.

2) PSM needs to display the 'orphaned' certs.... certificates that aren't user
certs, CA certs, peer certs or server certs so the user can delete them.

bob

Comment 5

[Wan-Teh Chang]

Bob,

Is it possible for NSS to detect that something is
wrong with this CA cert and NOT insert it into the
cert database?

Comment 6

[Kai Engert (:KaiE:)]

I like Bob's idea to think about showing orphan certs in Mozilla.

I have filed bug 164707 and already have created a patch (cloned code from other
views) to display those certs - not enabled by default, but activatable by
manually setting a pref.


Using that patch, I saw the orphan cert - after deleting it, the problem
mentioned in this bug went away.

Comment 7

[Stephane Saux]

I'm ok with turning the new cert category display on.

Comment 8

[Kai Engert (:KaiE:)]

This is currently a PSM bug, but the problem is in NSS.

Bob,

How should we deal with this bug?
Should NSS make sure it does not import that cert?
Should we have a corresponding NSS bug?

In comment 4 you say, you want to research why NSS is prefering this cert. Do
you want me to file a bug on that?

You also suggest that PSM should provide to show and delete Orphan certs.
I agree this is a good idea, but I fear, this will NOT help the user, since the
user probably won't know that it is required to delete a cert to fix the problem?

Comment 9

[Robert Relyea]

I think we need to take a 3 pronged approach to solving this bug.

Comment 10

[Robert Relyea]

Arg!!stupid form post...

OK I think we should take a 3 pronged approach to solving this bug:
Part 1) We should be smarter about how we build our chains, so that untrusted
roots don't interfere with our trusted roots. Ian, I think we put this change
into 3.6 just before we RTM'ed. Correct?

Part 2) We need to think about how we import certs from s/mime messages. as a
working strawman, I would propose we only import the encryption cert and it's
chain, and we only import the chain if it validates.

Part 3) We need to be able to see orphaned certs in the database to allow us to
debug these issues.

I think part 1 is done. Part 2 is either PSM or NSS (I think it's the NSS CMS
code that automatically loads the certs, but I'm not sure). Part 3 is PSM UI.

The problem identified in Comment 4 has been fixed in NSS 3.6 (and I think on
the tip of mozilla as well).

bob

Comment 11

[Wan-Teh Chang]

Bob wrote:
> The problem identified in Comment 4 has been fixed in NSS 3.6.

Should we mark bug 173706 as a duplicate then?

Comment 12

[Kai Engert (:KaiE:)]

> OK I think we should take a 3 pronged approach to solving this bug:
> Part 1) We should be smarter about how we build our chains, so that untrusted
> roots don't interfere with our trusted roots. Ian, I think we put this change
> into 3.6 just before we RTM'ed. Correct?

I didn't know you had already worked on that :)

I just repeated the steps from the original problem description.
I am no longer able to reproduce the bug.

If you agree, I suggest to resolve this bug and bug 173706 as fixed.


> Part 2) We need to think about how we import certs from s/mime messages. as a
> working strawman, I would propose we only import the encryption cert and it's
> chain, and we only import the chain if it validates.

You say "only its chain".
When you say "chain", do you mean "chain excluding toplevel root"?

I'd say:
- it is necessary to always import the entity's encryption cert
- it sounds fine, to only import any intermediate certs, if they validate

- by deciding to import the root cert only if it validates, we introduce a small
hurdle to the user. When the user receives a S/Mime message with a new CA, we
silently import the cert. The user can go to the cert manager and trust it. If
we do not import the CA cert, the user is unable to retrieve the untrusted root
by email. The user must use other ways to obtain the root cert, either importing
from a file or downloading from the web.

If we decide not to import the root cert automatically, it would be good to give
the user a UI to trigger it.

A potential place for this UI would be the "view message security info" dialog.
However, we currently do not display the encryption certificate, only the
signing certificate (in case they are different).

But not importing the root automatically would also have an advantage.
Currently, when we silently import the root, it's imported untrusted. If the
user tries to import the root from the web or from a file, the user expects to
see a "import confirmation" dialog, in association with the "decide how you want
to trust the cert". What we currently do is display an "cert already exists"
dialog, not showing the "edit trust", which might confuse users. We avoid the
"cert already exists" situation, because we wouldn't have already imported the
root silently.

I think the code that actually imports the certs is NSS/SMime, but we need to check.


> Part 3) We need to be able to see orphaned certs in the database to allow us to
> debug these issues.

I agree this would be a helpful thing.
But if I understand correctly, since you were able to fix this bug in NSS, there
is no longer an urgent need to do so.
But I understand the motivation to have this feature, to be able to analyze
problems.

However, I think we need to spend more thoughts on how the orphan category in
cert manager would behave.

As I said in comment 6, I had already filed bug 164707, and it already has a patch.

But I think using that patch as is might be confusing. We at least need to
discuss the following:

Currently, the "other people" certs tab displays only personal encryption certs.
It does not display signing certs. With the patch, those signing certs are shown
in the orphan tab.

I think we should avoid showing signing certs in the orphan certs tab, what do
you think? Should we show them in the "other people's certs" tab, too?


Please comment with your thoughts, but if I understand correctly, this bug is
now fixed on the trunk.

Comment 13

[Ian McGreer]

re: comment #10 and comment #12, yes, the changes to path construction went into
3.6 RTM.

Comment 14

[Robert Relyea]

OK, so a couple of issues:

RE root certs: Actually this bug was caused by an old intermediate, not a root. We
do not send root certs in our S/MIME messages anyway, so they are seldom imported.

yes I do mean the chain minus the root cert. In order to validate a cert, we do
need the intermediates. 

RE showing orphaned certs: The bug I fixed only solved the accidental nature of
this bug. Ian's fix in NSS 3.6 will probably handle the intentional use as well.
It is truly a bug, however, if we can import certs into our database and not be
able to have a way to see them. The user should not have to resort to certutil
to delete such certificates. At the very least someone could send you an email
which fills up your certdb with certificates that are 'invisible' and you
suddenly cannot understand why all your cert operations suddenly got much slower.

So the problem reported by this bug is fixed, but the problems that it exposed
are not all fixed. I think we need 2 separate bugs for those new issues, then we
can close this one.

bob

Comment 15

[Kai Engert (:KaiE:)]

You said, this bug is fixed.

I have filed bug 174483 to enhance the cert import strategy on incoming
messages. Bob, you were right, the importing is indeed done by PSM.

We already have bug 164707 to discuss and implement the orphan certs management UI.

Marking this bug as worksforme.

Comment 16

[Charles Rosendahl]

verf'd

Comment 17

[Kai Engert (:KaiE:)]

I think we have implemented the suggested import strategy in bug 249004.