Bug#721976: Roots trusted for email but not TLS

[Michael Prokop]

Hi,
* Andrew Ayer [Wed Dec 16, 2015 at 09:54:58AM -0800]:
> On Mon, 14 Dec 2015 21:59:27 -0600 Michael Shuler  
> wrote:

> > Thanks for your thoughts. A separate package is an interesting interim
> > idea, but in looking at what redhat has done, I think a more complete
> > transition to trust type buckets is preferred, along with including a
> > code-signing cert bucket. I think it's the extra package and updating
> > deps for a short-term solution that I'm not fond of. That would need
> > another update of deps and proper solution in the long term.

> Thanks for considering my suggestions.  While I agree that using
> separate trust buckets is the best solution, I'm concerned that the
> time it takes to triage and patch other packages will unnecessarily
> prolong the risk to users who don't even use S/MIME. So I suggest
> making the short-term solution a stepping stone for the long-term
> solution, so that work doesn't have to be undone later.

> Specifically, I propose changing the ca-certificates source package to
> generate three binary packages:

>   1. ca-certificates-server

>   2. ca-certificates-email

>   3. ca-certificates - a metapackage that depends on
>   ca-certificates-server, and (at most) suggests ca-certificates-email
[...]

I stumbled upon this issue via
https://github.com/certifi/python-certifi/issues/35
and I'm wondering if there has been any progress with it?

regards,
-mika-


signature.asc
Description: Digital signature

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

Hi Michael,

On Mon, 14 Dec 2015 21:59:27 -0600
Michael Shuler  wrote:

> Thanks for your thoughts. A separate package is an interesting interim
> idea, but in looking at what redhat has done, I think a more complete
> transition to trust type buckets is preferred, along with including a
> code-signing cert bucket. I think it's the extra package and updating
> deps for a short-term solution that I'm not fond of. That would need
> another update of deps and proper solution in the long term.

Thanks for considering my suggestions.  While I agree that using
separate trust buckets is the best solution, I'm concerned that the
time it takes to triage and patch other packages will unnecessarily
prolong the risk to users who don't even use S/MIME. So I suggest
making the short-term solution a stepping stone for the long-term
solution, so that work doesn't have to be undone later.

Specifically, I propose changing the ca-certificates source package to
generate three binary packages:

1. ca-certificates-server

2. ca-certificates-email

3. ca-certificates - a metapackage that depends on
ca-certificates-server, and (at most) suggests ca-certificates-email

For now, ca-certificates-server and ca-certificates-email will install
roots to the same location.  Once separate root stores are supported,
it will be a simple change to these packages to install to separate
locations instead.

Other packages could continue to depend on just ca-certificates because
it will pull in ca-certificates-server automatically. Over time,
packages could be modified to have a more fine-grained dependency on
ca-certificates-server and/or ca-certificates-email, but there's no
urgency to this and there would be no need to switch dependencies back
later.  In fact, until separate stores are supported, *no* package
should depend on ca-certificates-email, not even MUAs that support
S/MIME. Just because a MUA supports S/MIME doesn't mean that users use
it. The majority of users of such MUAs only need root certificates for
secure SMTP/IMAP/POP, not S/MIME, and they should be able to avoid the
email-only roots until they're properly segregated.

As for the code signing trust store, note that Mozilla is
discontinuing their code signing root program[1], so Debian would need
to either operate its own root program or find another root program to
use for code signing.  Do you know if there is any demand for
code-signing roots in Debian?

I should also mention that Mozilla's email trust store is on life
support, and is at risk of being discontinued if no one steps up to help
maintain it[2].  Splitting it into a separate package in Debian could
be a good way to get the word out to people who rely on it that they
should consider contributing upstream to prevent its discontinuation.

Regards,
Andrew


[1] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02409.html

[2] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02413.html

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

Hi Michael,

Have you given any more thought to a redesign of ca-certificates that
separates the email certificates from the TLS certificates?  I suspect
that the vast majority of packages that depend on ca-certificates use
it for TLS server auth, and yet there are currently 21 roots in the NSS
store that are trusted for email but distrusted for TLS server auth:

 1  AC Ra\xC3\xADz Certic\xC3\xA1mara S.A. 
 2  ComSign CA 
 3  Equifax Secure CA  (1024-bit)
 4  Equifax Secure Global eBusiness CA  (1024-bit)
 5  Equifax Secure eBusiness CA 1  (1024-bit)
 6  NetLock Business  (1024-bit)
 7  NetLock Express  (1024-bit)
 8  NetLock Qualified 
 9  S-TRUST Authentication and Encryption Root CA 2005 PN 
10  S-TRUST Universal Root CA 
11  Sonera Class 1 Root CA 
12  SwissSign Platinum CA - G2 
13  TC TrustCenter Class 3 CA II 
14  UTN USERFirst Email Root CA 
15  Verisign Class 1 Public Primary Certification Authority  (1024-bit)
16  Verisign Class 1 Public Primary Certification Authority - G2  (1024-bit)
17  Verisign Class 1 Public Primary Certification Authority - G3 
18  Verisign Class 2 Public Primary Certification Authority - G2  (1024-bit)
19  Verisign Class 2 Public Primary Certification Authority - G3 
20  Verisign Class 3 Public Primary Certification Authority  (1024-bit) 
(non-BR-compliant)
21  Verisign Class 3 Public Primary Certification Authority - G2  (1024-bit)

Ten of these are 1024-bit RSA roots.  Over the past year, Mozilla has
been removing the TLS trust bit from 1024-bit roots, and at long last
the NSS root store no longer contains any 1024-bit roots trusted for
TLS. Unfortunately, Debian applications continue to trust them for TLS.
This reduces the security of TLS authentication down to the cost of
factoring just one of these 1024-bit roots.  It would be great to bring
the security level of Debian's root store up to 2048 bits for TLS.

In addition, the "Verisign Class 3 Public Primary Certification
Authority" root (owned by Symantec) is still trusted despite its TLS
trust bit being removed in NSS.  As of December 1, 2015, this root is
being used to issue certificates that don't comply with the Baseline
Requirements:


https://googleonlinesecurity.blogspot.com/2015/12/proactive-measures-in-digital.html

As such, this root should be distrusted ASAP.

As always, let me know if you could use any help.  I'm going to start
looking through the reverse depends for ca-certificates to identify
packages that might be relying on roots for email authentication.

Thanks,
Andrew

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

On Mon, 14 Dec 2015 18:45:40 -0600
Michael Shuler  wrote:

> > As always, let me know if you could use any help.  I'm going to
> > start looking through the reverse depends for ca-certificates to
> > identify packages that might be relying on roots for email
> > authentication.
> 
> Exactly. I also do not know if pointing mail-related CAs to another
> filesystem location and patching mail-related packages to look there
> is sufficient - are there mail clients/utilities that also open https
> web urls?

It wouldn't be a question of HTTPS connections, but rather TLS
connections to IMAP, POP, and SMTP servers, which most MUAs will make.
MUAs that implement S/MIME should use separate trust stores for TLS and
S/MIME (or have some other way to distinguish between roots) and MUAs
that don't are buggy.  I would be interested in patching such MUAs,
although this would be a long-term effort.

Fortunately, there is a simple short-term solution that could be
implemented immediately and would provide a security improvement to the
majority of Debian users without removing any functionality: ship the
email-only roots in a separate package.  I suspect that only a small
minority of Debian users use S/MIME, whereas a large majority of users
use wget, curl, git, etc. with HTTPS, or MUAs with secure SMTP/IMAP/POP
(but not S/MIME).  The minority can install the S/MIME roots and have
the same security and functionality as now, while the majority
will benefit from better security.  Is this an acceptable solution
pending a long-term effort to assess and improve trust store handling
in MUAs?

Regards,
Andrew

Bug#721976: Roots trusted for email but not TLS

[Michael Shuler]

On 12/14/2015 06:18 PM, Andrew Ayer wrote:
> Hi Michael,
> 
> Have you given any more thought to a redesign of ca-certificates that
> separates the email certificates from the TLS certificates?  I suspect

Yep - got a patch?  :-)

> that the vast majority of packages that depend on ca-certificates use
> it for TLS server auth

Got patches for all the mail-related rdeps of ca-certificates?  :-)

I have not gone through every rdep package to cound, but there are quite
a few mail-related pacakges, so they should each have some new
filesystem location to search for mail-specific CA certificates.

> As always, let me know if you could use any help.  I'm going to start
> looking through the reverse depends for ca-certificates to identify
> packages that might be relying on roots for email authentication.

Exactly. I also do not know if pointing mail-related CAs to another
filesystem location and patching mail-related packages to look there is
sufficient - are there mail clients/utilities that also open https web urls?

-- 
Kind regards,
Michael

Bug#721976: Roots trusted for email but not TLS

[Michael Shuler]

On 12/14/2015 07:45 PM, Andrew Ayer wrote:
> On Mon, 14 Dec 2015 18:45:40 -0600
> Michael Shuler  wrote:
> 
>>> As always, let me know if you could use any help.  I'm going to
>>> start looking through the reverse depends for ca-certificates to
>>> identify packages that might be relying on roots for email
>>> authentication.
>>
>> Exactly. I also do not know if pointing mail-related CAs to another
>> filesystem location and patching mail-related packages to look there
>> is sufficient - are there mail clients/utilities that also open https
>> web urls?
> 
> It wouldn't be a question of HTTPS connections, but rather TLS
> connections to IMAP, POP, and SMTP servers, which most MUAs will make.
> MUAs that implement S/MIME should use separate trust stores for TLS and
> S/MIME (or have some other way to distinguish between roots) and MUAs
> that don't are buggy.  I would be interested in patching such MUAs,
> although this would be a long-term effort.
> 
> Fortunately, there is a simple short-term solution that could be
> implemented immediately and would provide a security improvement to the
> majority of Debian users without removing any functionality: ship the
> email-only roots in a separate package.  I suspect that only a small
> minority of Debian users use S/MIME, whereas a large majority of users
> use wget, curl, git, etc. with HTTPS, or MUAs with secure SMTP/IMAP/POP
> (but not S/MIME).  The minority can install the S/MIME roots and have
> the same security and functionality as now, while the majority
> will benefit from better security.  Is this an acceptable solution
> pending a long-term effort to assess and improve trust store handling
> in MUAs?

Thanks for your thoughts. A separate package is an interesting interim
idea, but in looking at what redhat has done, I think a more complete
transition to trust type buckets is preferred, along with including a
code-signing cert bucket. I think it's the extra package and updating
deps for a short-term solution that I'm not fond of. That would need
another update of deps and proper solution in the long term.

I guess I'd have to see how many other packages this affects.

-- 
Kind regard,
Michael