887431 - S/MIME broken by missing all free CAs CLASS 1 intermediate CA- certificates

Status: RESOLVED INVALID

(Core :: Security, defect)

Description

[t.schorpp]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20101020004739

Steps to reproduce:

Enrolled for most free (costless) available S/MIME- certificates, like suggested and listed here:
http://kb.mozillazine.org/Getting_an_SMIME_certificate


Actual results:

None of them usable because for signing(/encryption) because all of those CAs use Mozilla non included but own intermediate CAs for issuing those free CLASS 1 certs.

So users have to manually download and import the intermediate certs, what may introduce security risks because of the users' need of advanced system, client-server and PKI security knowledge most consumer/free users don't have and don't have the time for learning it.

So this issue renders S/MIME- functionality in Thunderbird and Suite 

actually... to nothing, 

since self-signed certificates have to be considered as a security policy violation of the X.509 certificates S/MIME- PKI- system because of missing trust/intend anchors.



Expected results:

CAs issuing free S/MIME- certificates should have been able to apply for inclusion of their own in-chain- intermediate CAs without the need for expensive commercial extra audits 

or should have applied at all.

Comment 1

[t.schorpp]

Raising priority, reason:
http://rt.com/news/germany-spied-nsa-snowden-515/
You've all got the bad news.

NSA's illegal international practices may be acceptable to some U.S. folks but not to the majority of the world.

Please vote for this and other related bugs, thank You very much.

Comment 2

[Mark Banner (:standard8)]

The StartCom certificate works fine for me for signing. Never tried any of the rest.

Moving to Core/Security as certificates are controlled in core.

Comment 3

[t.schorpp]

Useless because verification fails in at least TB latest release due to bug topic:

$ /usr/local/bin/certutil -L -d xxxxxxx |grep -w 'Class 1 Primary Intermediate Client CA'
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. c,c,c
schorpp@tom3:~$

schorpp@tom3:~$ p7content -d xxxxxx -i ~/Projects/keymanager/smime.p7s
Content printed between bars (newline added before second bar):
---------------------------------------------

---------------------------------------------
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is [e-mail]
The signer's email address is [e-mail]
Signing time: Thu Jun 20 08:22:52 2013
There were certs or crls included.
schorpp@tom3:~$ p7verify -d xxxxxxxx -c enigerr.txt -s ~/Projects/keymanager/smime.p7s
Signature is invalid (Reason: Peer's Certificate issuer is not recognized.).
schorpp@tom3:~$ 

schorpp@tom3:~$ 
schorpp@tom3:~$ p7content -d xxxxxxxx -i ~/Projects/keymanager/mbanner.p7s
Content printed between bars (newline added before second bar):
---------------------------------------------

---------------------------------------------
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is [e-mail]
The signer's email address is [e-mail]
Signing time: Wed Jun 19 09:36:51 2013
There were certs or crls included.
schorpp@tom3:~$ p7verify -d xxxx -c enigerr.txt -s ~/Projects/keymanager/mbanner.p7s
Signature is invalid (Reason: Peer's Certificate issuer is not recognized.).
schorpp@tom3:~$ 

schorpp@tom3:~$ /usr/local/bin/certutil -L -d xxxx |grep -w 'Class 1 Primary Intermediate Client CA'
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. c,C,c
schorpp@tom3:~$

schorpp@tom3:~$ p7verify -d xxxxx -c enigerr.txt -s ~/Projects/keymanager/mbanner.p7s
Signature is invalid (Reason:[...] corrupted data.).
schorpp@tom3:~$ 
But "recognized" now.

CONFIRMED enough now?

BTW:
schorpp@tom3:~$ signver -H |grep signatureFileName
 -s signatureFileName  input file for signature (default stdin)
schorpp@tom3:~$ signver -A -d xxx -s ~/Projects/keymanager/smime.p7s
signver: unable to open "/home/schorpp/Projects/keymanager/smime.p7s" for writing.
schorpp@tom3:~$

Latest NSS tools release.

Comment 4

[Mark Banner (:standard8)]

Please leave the priority field alone, that is for developer use.

Comment 5

[t.schorpp]

I'am a developer, please google for the code.

Comment 6

[t.schorpp]

(In reply to Mark Banner (:standard8) from comment #2)

> Moving to Core/Security as certificates are controlled in core.

1.
I've seen only the MUA of Mozilla, Thunderbird, affected from this bug, since we don't have S/MIME on the transport layer of MTAs, nor do we have it on HTTPS- servers and not many of such webservers accept Email Signer Certs for authentication, have we?
This is an application layer bug and the application handling S/MIME is Thunderbird, or am I mistaking?
Is anyone around still using the "suite"?

2.
May any other people comfirm/review 
https://bugzilla.mozilla.org/show_bug.cgi?id=887431#c3
? 

It's easy to build the NSS PKCS7 tools, no need to be a experienced full time job programmer:
https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing
it's not included in some Linux distribution packages:
http://packages.debian.org/sid/i386/libnss3-tools/filelist
http://packages.ubuntu.com/precise/i386/libnss3-tools/filelist

You can download the startcom intermediate CA test objects here:
http://mail.mozilla.org/pipermail/tb-planning/attachments/20130619/e0dd7990/attachment.p7s
https://groups.google.com/forum/#!topic/tb-planning/7GFNLm_GC_4
https://groups.google.com/group/tb-planning/attach/bdf37cd7af1d9909/smime.p7s?part=5
https://groups.google.com/group/tb-planning/attach/d16739835f33a628/smime.p7s?part=5

?

Comment 7

[Kaspar]

(In reply to t.schorpp from comment #6)
> (In reply to Mark Banner (:standard8) from comment #2)
> 
> > Moving to Core/Security as certificates are controlled in core.
> 
> 1.
> I've seen only the MUA of Mozilla, Thunderbird, affected from this bug,
> since we don't have S/MIME on the transport layer of MTAs, nor do we have it
> on HTTPS- servers and not many of such webservers accept Email Signer Certs
> for authentication, have we?
> This is an application layer bug and the application handling S/MIME is
> Thunderbird, or am I mistaking?

You're both mistaken and missing several points, yes:

- p7verify is definitely not the appropriate NSS tool for verifying S/MIME signatures nowadays (use cmsutil instead)

- The S/MIME handling glue code mostly lives under mailnews/extensions/smime/src (there's no mail/extensions/smime/src), which is the reason for comment 2

- Your statement in comment 0 ("because all of those CAs use Mozilla non included but own intermediate CAs for issuing those free CLASS 1 certs") is inacurrate/irrelevant. The signerInfo elements in the S/MIME signatures you're linking to in comment 6 certainly do include the intermediate CA certs (as stipulated in RFC 5652 section 5.1).

- The "c" flag is not sufficient for a CA to be trusted for verifying certs (you need to have "C", and your cert DB must also load the nssckbi module ["Builtin Roots"], otherwise you're not mimicking Tb's behavior with the command-line tools).

- "S/MIME on the transport layer of MTAs": but you do know that S/MIME is about message-level security, not about transport-layer security (aka TLS), don't you? You might want to have a look at http://en.wikipedia.org/wiki/OSI_model otherwise.

I suggest you do some more homework before claiming that Tb (or even NSS/libsmime) is at fault re: intermediate CA certificates in S/MIME messages.

Comment 8

[t.schorpp]

(In reply to Kaspar Brand from comment #7)
> (In reply to t.schorpp from comment #6)
> > (In reply to Mark Banner (:standard8) from comment #2)
> > 
> > > Moving to Core/Security as certificates are controlled in core.
> > 
> > 1.
> > I've seen only the MUA of Mozilla, Thunderbird, affected from this bug,
> > since we don't have S/MIME on the transport layer of MTAs, nor do we have it
> > on HTTPS- servers and not many of such webservers accept Email Signer Certs
> > for authentication, have we?
> > This is an application layer bug and the application handling S/MIME is
> > Thunderbird, or am I mistaking?
> 
> You're both mistaken and missing several points, yes:
> 
> - p7verify is definitely not the appropriate NSS tool for verifying S/MIME
> signatures nowadays (use cmsutil instead)

Why? What's not working?

8  * $Id: p7verify.c,v 1.11 2012/03/20 14:47:13 gerv%gerv.net Exp $
8  * $Id: cmsutil.c,v 1.55 2012/03/20 14:47:20 gerv%gerv.net Exp $

nowadays == nowadays

And fails Your "attacker" check 
http://lxr.mozilla.org/mozilla/source/security/nss/cmd/smimetools/cmsutil.c#300
and / or
http://lxr.mozilla.org/mozilla/source/security/nss/cmd/smimetools/cmsutil.c#285
" 		** or might be an invalid message, such as a QA test message" ^^

schorpp@tom3:~$ cmsutil -v -D -i ~/Projects/keymanager/smime.p7s -u 4 -d xxxxxx 
received commands
NSS has been initialized.
Got default certdb
cmsutil: no message digests: SEC_ERROR_EXTENSION_NOT_FOUND: Certificate extension not found.
cmsutil: problem decoding: SEC_ERROR_EXTENSION_NOT_FOUND: Certificate extension not found.
schorpp@tom3:~$ 
http://lxr.mozilla.org/mozilla/source/security/nss/cmd/smimetools/cmsutil.c#300

> 
> - The S/MIME handling glue code mostly lives under
> mailnews/extensions/smime/src (there's no mail/extensions/smime/src), which
> is the reason for comment 2

That's Your code organisation talent.

> 
> - Your statement in comment 0 ("because all of those CAs use Mozilla non
> included but own intermediate CAs for issuing those free CLASS 1 certs") is
> inacurrate/irrelevant. The signerInfo elements in the S/MIME signatures
> you're linking to in comment 6 certainly do include the intermediate CA
> certs (as stipulated in RFC 5652 section 5.1).

http://tools.ietf.org/html/rfc5652#page-8
 certificates [0] IMPLICIT CertificateSet OPTIONAL,

http://tools.ietf.org/html/rfc5652#section-5.2.1
http://tools.ietf.org/html/rfc5652#section-5.6
The selection and validation
   of the signer's public key MAY be based on certification path
   validation (see [PROFILE])

So p7verify is behaving actually correct and compatible, cmsutil seems not or broken.

File a bug?

> 
> - The "c" flag is not sufficient for a CA to be trusted for verifying certs
> (you need to have "C", 

Already confirmed in c3.

> and your cert DB must also load the nssckbi module
> ["Builtin Roots"], otherwise you're not mimicking Tb's behavior with the
> command-line tools).

Pardon?  Theres no such command line option in cmsutil, programmer's job.
A "DB" is a storage resource not computable code, I can not tell a DB to load a shared program code object, if You can, show how, "developers only", Banner said. I'm an moron user.
Besides readelf and ldd do not show up this lib.

> 
> - "S/MIME on the transport layer of MTAs": but you do know that S/MIME is
> about message-level security, not about transport-layer security (aka TLS),
> don't you? You might want to have a look at
> http://en.wikipedia.org/wiki/OSI_model otherwise.

https://bugzilla.mozilla.org/show_bug.cgi?id=887431#c6 1.)
http://en.wikipedia.org/wiki/OSI_model#Layer_7:_application_layer
Application-layer functions typically include *identifying communication partners*, determining resource availability, and synchronizing communication. When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit.

> 
> I suggest you do some more homework before claiming that Tb (or even
> NSS/libsmime) is at fault re: intermediate CA certificates in S/MIME
> messages.

Thanks for the comments and nice programmer's discussion, but this bug is not trigger'd by faulty program code, wrong design/implementation, 

it is triggered by missing data resources, namely intermediate certificates.

Since Mozilla has grown up to the big ones who can afford grave bugs, I'll switch to KMail/gpgsm on upgrading to debian stable, thanks for the Years of service.

Comment 9

[Kaspar]

(In reply to t.schorpp from comment #8)
> > - p7verify is definitely not the appropriate NSS tool for verifying S/MIME
> > signatures nowadays (use cmsutil instead)
> 
> Why? What's not working?
> 
> 8  * $Id: p7verify.c,v 1.11 2012/03/20 14:47:13 gerv%gerv.net Exp $
> 8  * $Id: cmsutil.c,v 1.55 2012/03/20 14:47:20 gerv%gerv.net Exp $
> 
> nowadays == nowadays

Did you actually check what the purpose of these commits was? Modifications of license text should hardly be taken as an indication of code being actively maintained. Instead, you might want to read

https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/eKHFHKJan9U/CQNayGV0x5wJ


> schorpp@tom3:~$ cmsutil -v -D -i ~/Projects/keymanager/smime.p7s -u 4 -d
> xxxxxx 

Well, you need to specify where the message content (-c) can be found...


> http://tools.ietf.org/html/rfc5652#section-5.2.1
> http://tools.ietf.org/html/rfc5652#section-5.6
> The selection and validation
>    of the signer's public key MAY be based on certification path
>    validation (see [PROFILE])
> 
> So p7verify is behaving actually correct and compatible, cmsutil seems not
> or broken.
> 
> File a bug?


No. For S/MIME certificate handling, see RFC 5750 section 4.2:

   Certificate, CRL, and path
   validation MUST be performed as per [KEYM] when validating a
   correspondent's public key.

(where [KEYM] is a reference to RFC 5280)


> > and your cert DB must also load the nssckbi module
> > ["Builtin Roots"], otherwise you're not mimicking Tb's behavior with the
> > command-line tools).
> 
> Pardon?  Theres no such command line option in cmsutil, programmer's job.
> A "DB" is a storage resource not computable code, I can not tell a DB to
> load a shared program code object, if You can, show how, "developers only",
> Banner said. I'm an moron user.
> Besides readelf and ldd do not show up this lib.


I'm not interested in arguing about the semantics of "DB" vs "code", sorry. But if you look in your "xxxxxx" directory, you'll discover a secmod.db file there. Read https://developer.mozilla.org/en-US/docs/NSS_tools_:_modutil if you're wondering what it is about.


> it is triggered by missing data resources, namely intermediate certificates.

Again, this is an incorrect conclusion (from you attempts to demonstrate the problem via NSS command-line tools). If you really think that Tb fails to verify S/MIME messages signed by a cert from Startcom, Comodo etc. (in contrast to other MUAs, which apparently succeed in doing so, according to your comment 6), then please attach a complete message file (message/rfc822) to this bug for further analysis.