36623 - Cryptic error replying to unreadable encrypted message

Status: NEW

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

Description

[lenz]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #69175
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=69175
Imported into Bugzilla on 04/20/00 17:30)

Someone sends me an encrypted message.  I can't read it (either I forgot my 
password, or don't have a valid Policy file).  So I try to reply to the message 
and ask, "What does this say?"  When I try to send my reply I get a cryptic 
error--"operation cannot be performed because required algorithm is not 
supported in the current configuration".  That is rather daunting for the 
average user!  Users should be able to reply to an encrypted message they can't 
read, I would think.  If not, give me an understandable error, and give it to me 
before rather than after I compose my message.


------- Additional Comments From trudelle  05/30/97 14:33 ------- 

reassigned to jsw


------- Additional Comments From repka  06/11/97 10:15 ------- 

Sorry for the delay (I was out on vacation), but just to clarify -- you
*can* reply to an encrypted message.  What you maybe didn't notice was that
your *reply* was marked to be encrypted, but you were not allowed to encrypt
for some reason (missing policy file?), and that is what the error was
trying to tell you -- if you had unchecked the encryption box on the
compose window you would have been able to send (you could even do this
after OKing the error dialog -- your composition was still there, you
just needed to stop trying to send an encrypted message).

Anyway, fixing the error handling is a bigger problem than you might
imagine -- that error is generated in some low-level code which does
not even know that you are creating a mail message.  Making a clearer
message requires more context than our current client error handling
mechanism provides us.  It's on the list of things that needs to
improve (and has been since I started working here ;-).

------- Additional Comments From marek  Apr-03-2000 18:12 ------- 

mass resolving LATER and REMIND bugs as WONTFIX (however, if you own one of 
these and have a fix that can be checked into 4.73 [assuming that you have QA 
lined up for it], please contact 4.73 project manager -- angelabu)

Comment 1

[Lisa Repka]

Old bug just moved from internal to bugzilla.  Reopening so I can
reassign it and comment on it.

Comment 2

[Lisa Repka]

Chris, this bug is a about a usability problem.  It only occurs on an error
condition, but when you get around to looking at such usability things, you
may want to try to improve it.  It's part of a bigger class of problems -- what
does the user get told when he can't decrypt a message, can't encrypt a message,
etc.  The code in this case didn't do anything "wrong", it's just that what
the user saw was not helpful.  This is only barely an NSS bug, in that the
low-level error setting is done there.  It may be more fitting as a PSM bug,
but I'll leave that level of categorization detail up to you.

Comment 3

[Wan-Teh Chang]

Set Target Milestone 4.0.

Comment 4

[Wan-Teh Chang]

Assigned the bug to Julien.  Note the target milestone
is 4.0.

Comment 5

[Julien Pierre]

I need more information about this. What is the policy file ?
The way this defect is written, it seems to me like it may be an application
issue rather than NSS.

Comment 6

[Julien Pierre]

The original bug was reported against an application, Netscape communicator 4.73
. I don't see this problem happening in Mozilla today.
There is no good description of what the error NSS was, and I'm not sure this
still applies today.

I would be in favor of closing this bug invalid, unless somebody is able to
figure out what the NSS problem is from the description.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

The particular error message cited in the original report was an error that
occurs when you attempt to send an encrypted message to an S/MIME correpondent.
It was equivalent of SSL's "No overlapping cipher" error.  

A correpondent has previously sent you a signed email, containing an SMIME
profile indicating that his SMIME client only supports a certain cipher (and 
key strength).  Your client does not support that cipher/key strength, so 
you cannot encrypt a message to him in his preferred cipher.  

It is likely that this was originally caused by the use of an "export" 
version of the email client, or (as the reporter surmised) a lost or
corrupted crypto policy file.  

I think the possibility still exists that we may not be able to encrypt a
message using the algorithm specified by some correspondent.  When that
happens, the error message presented to the user should make it clear 
what the problem is and what the user's choices are in dealing with the
problem.  In this case, the choices would likely be (a) don't send it, 
or (b) send it unencrypted.  

In any case, I think this probably should have been a PSM bug, not NSS.

Comment 8

[Julien Pierre]

There are several possible issues here - mismatched key exchange algorithms
(KEA), and mismatched bulk cipher algorithms.

Examining the lib/smime code, I see this comment :

    /* now we need to have a proper content encryption algorithm
     * on the SMIME level, we would figure one out by looking at SMIME capabilities
     * we cannot do that on our level, so if none is set already, we'll just go
     * with one of the mandatory algorithms (3DES) */

If 3DES is mandatory to implement, then this error should never exist.

On the other hand, the function "smime_choose_cipher", which tries to find a
cipher agreeable to multiple recipients, selects SMIME_RC2_CBC_40 by default. 

There doesn't appear to be a way to enable/disable the S/MIME ciphers that are
valid in the new S/MIME API, except for Fortezza which has a PRBool to turn it
on/off. Otherwise, all the supported symettric ciphers from "smime_cipher_map"
are automatically added to the S/MIME capabilities in outgoing messages.

I don't think the original error can even happen with the API from lib/smime for
bulk ciphers. 

In lib/pkcs7, things are slightly different. There is a
PR_SetError(SEC_ERROR_BAD_EXPORT_ALGORITHM) if smime_export_capabilities is 0.

In both libraries, there is also a case of SEC_ERROR_INVALID_ALGORITHM that is
set if no matching KEA is found.

Based on these findings, I would say that the original bug may have been fixed.
At the very least, NSS seems to be setting error codes appropriately. It's
possible the error code was reset somewhere in the stack and lost when it got to
the application (PSM). I will try to artifically recreate this error and see if
it gets reported back to the application.

Comment 9

[Julien Pierre]

I have confirmed that the proper error code gets set. Mozilla does not display
an error box that explains why encryption failed, it just said it could not
encrypt. So this is not an NSS bug, but a PSM bug. Reassigning to Kai, who is
probably the only one working on PSM at this point ...