84213 - S/MIME should not support weak crypto

Status: NEW

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

Description

[Robert Relyea]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010605
Netscape6/6.1b1
BuildID:    N/A

We need a function in the browser which will lock out sending email messages to
certain users or in general which aren't strongly encrypted.

The reason for this is there are some environments where our users need to
securely communicate in countries where their religious and political freedoms
are impaired. These countries  collect email and web data comming through their
firewalls, and weakly encrypted data, or unencrypted data with particular key
words are targetted.

For these cases we need to provide means in which users can ask the browser's
assistance in preventing weakly encrypted or unencrypted data from leaving the
machine.

David, this is really an eClient bug, but I couln't find an eClient component.
Mark it target fix in the future (It's a place holder for when we discuss this
encryption.

Reproducible: Didn't try

Comment 1

[Stephane Saux]

target -> future
P2

Comment 2

[John Unruh]

Mass assigning QA to ckritzer.

Comment 3

[Sebastian Späth]

If this bug is simply requesting S/MIME support in Mozilla MailoNews it should
be duped as bug 74157

Comment 4

[John Unruh]

This really looks like a dupe of bug 74157. Also, alam's test plan should handle
warning dialog testing. http://eclient.mcom.com/qa/emojo/tests/smime/smime_func.html

*** This bug has been marked as a duplicate of 74157 ***

Comment 5

[Bob Lord]

This is not a dup.  I've changed the title from
S/MIME support in Mozilla Mail
to
S/MIME should not support weak crypto
in order to better spell out the request.

Comment 6

[gsa]

this story gives reasons why S/MIME shouldn't be used at all.
http://wired.com/news/technology/0,1282,7220,00.html

Comment 7

[Stephane Saux]

You don't need a distributed attack to crack weak crypto.  One computer is
enough.  I don't see how a well established truth about cryptography in general
invalidates S/MIME.  It should invalidate weak crypto, which this bug is about.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign ddrinan's PSM bugs (with his permission) to nobody

Comment 9

[Nicholas Sushkin]

Perhaps a configuration option can be added to disable certain smime algorithms. For example, I'd like to disable RC2 algorithm in Thunderbird's S/MIME encryption, because I cannot read RC2 encrypted S/MIME email with KMail or gpgsm.

http://steffenpingel.de/news/archive/2006/mar/05/reading-mails-encrypted-by-thunderbird-with-kmail/

http://www.nabble.com/gpgsm-1.9.22-supports-no-RC2-Algorithm---tf3581426.html

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Correcting the bug's component.  Should be S/MIME

Comment 11

[Kai Engert [:KaiE:]]

File mozilla/security/nss/lib/smime/smimeutil.c
has a map named smime_cipher_map.
It lists all supported S/Mime ciphers and currently has them all enabled.

I propose we introduce a separate preference for each of them.
Then we could consider to disable the weak ciphers by default for TB 3 / SM 1.5

SMIME_RC2_CBC_40
SMIME_DES_CBC_56
SMIME_RC2_CBC_64
SMIME_RC2_CBC_128
SMIME_DES_EDE3_168
SMIME_AES_CBC_128
SMIME_FORTEZZA

Comment 12

[Magnus Melin [:mkmelin]]

https://searchfox.org/comm-central/rev/8d05752f683d1c7ae8bf85d9584fc6418427b104/mozilla/security/nss/lib/smime/smimeutil.c#109-120

Which ones are considered weak today?

Comment 13

[Magnus Melin [:mkmelin]]

Link: https://searchfox.org/mozilla-central/rev/9193635dca8cfdcb68f114306194ffc860456044/security/nss/lib/smime/smimeutil.c#109-120

Comment 14

[Joaquín Serna]

@mkmelin (In reply to Magnus Melin [:mkmelin] from comment #12)

Which ones are considered weak today?

According to the S/MIME V4.0 RFC:

Algorithms such as RC2 are considered to be weak encryption algorithms. Algorithms such as TripleDES are not state of the art and are considered to be weaker algorithms than AES.

It also says that AES-128 GCM and AES-256 GCM must be supported and ChaCha20-Poly1305 should also. It doesn't say anything about AES-256 CBC but AES-128 CBC must be supported so I guess the same applies to the same algorithm with stronger keys. According to the RFC v3.2 AES-192 CBC and AES-256 CBC should be supported.
https://datatracker.ietf.org/doc/html/rfc8551#section-2.7

So to answer your question I would say these are considered weak today:

• SMIME_RC2_CBC_40
• SMIME_DES_CBC_56
• SMIME_RC2_CBC_64
• SMIME_RC2_CBC_128
• SMIME_DES_EDE3_168

Comment 15

[Magnus Melin [:mkmelin]]

Based on https://searchfox.org/mozilla-central/rev/e409c755f313f6befb2c00f260bf873ccc191924/security/nss/lib/smime/smimeutil.c#113-117 and https://searchfox.org/mozilla-central/rev/e409c755f313f6befb2c00f260bf873ccc191924/security/nss/lib/pkcs7/secmime.c#361,383 it seems we're still using algorithms we shouldn't?

Comment 16

[Kai Engert [:KaiE:]]

Hmm, why don't the links from comment 15 work for me? Is searchfox service disrupted in some way?

Comment 17

[Magnus Melin [:mkmelin]]

Gah, can't permalink to /mozilla/ parts of comm-central searchfox. I've updated the links so they work now.