freebsd security - Jul 2014 - RFC: Proposal: Install a /etc/ssl/cert.pem by default?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Currently, FreeBSD does not install a default /etc/ssl/cert.pem
because we do not maintain one ourselves.  We do, however, provide a
port, security/ca_root_nss, which have an option to install a symbolic
link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt,
which is not the default option.

This become a problem when applications, e.g. fetch(8), have grown the
support of doing certificate validation.  I think now it makes sense
to have a default cert.pem installed with the base system.

So my proposal would be:

1. Import a set of trusted root certificates, and install if
MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;

2. In src/etc/Makefile, automatically create a symbolic link if it's
not already present in ${DESTDIR}/etc/ssl;

3. Teach mergemaster(8) and other similar applications to create the
symbolic link on demand;

4. Change the install/deinstall behavior of security/ca_root_nss:
   ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
install then overwrite with new symlink, and restore on deinstall.
   ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
install new a symlink; on deinstall, if
/usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
symlink to there, or remove if the file does not exist.

Comments/objections?

Cheers,
- -- 
Xin LI <delphij at delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJTtJmxAAoJEJW2GBstM+nsGoQQAJ8Ntso43Lz5YiwVVoar4BsZ
2d5YCv9ODyIVTHQMqz1lOP51NxzgvNPY4Ycdez0CEK8Az4VSSdouQJoBHRp70nCR
1ulMlZ06SXp8EcvPkDHFJC+1CbYu7ezSwgXLndj+7nOtXqr2t12/EccT40+YRNMN
zCUTHDWSdiuwNL9TLzDmyEO1oCcgej+zY5rSbVHiUWLQPUPG2ffvaddKCggJoRpp
rV/35H7aYNB1LzBpUp0/wisXvNrkXQh4YcH0e2Z7ILwn6GImE8gWex1hi0yndDeW
7wg+0e4HnwrjZrvNCqeggO+7owCYjE4mnb1qexBTrjvkeAKSjTvkiJzrS14S7yO2
Zj2d9S6504M/28i7+QdzANTrqD6yig6HHT5uL6MiSCnaW6G9+mjVB0OljXHCBARg
hFtKUxuVJFDANrbs5AmMwA3euLVHUuPtBL/t+yLSoobdVdvTcukftl7i6l86GDlw
rVyl57KLSwInAWZLox0+oPXacEwBYk/K0W1VdmbanLO8q2rdNDD5sKJP2I278LjT
wYGgjBOWuNfQTAKK13NMrat8DyvMM6lj5fhKkTDrKU6gEwoDeWsOsc5zKF2+lEGU
9nBi0Ll8jaQ3DBlOJcYa6VZMrgBe6dMRxhus0fVQYX8VKpezTwGGWh7Mdb+AJJxx
DN4UDkFEYreAP4szDYHC
=zwfk
-----END PGP SIGNATURE-----

On 07/03/14 01:45, Xin Li:
> 1. Import a set of trusted root certificates

Question is imminent ...

Trusted by whom ?

Trust is matter of personal decision, local law and law that apply to 
particular CA.

If I consider a CA to be trustworthy, I will insert it's certificate to 
trusted store. No one is welcomed to make such decision in behalf of me.

Just my $0.02

Dan

+portmgr

On 7/2/2014 6:45 PM, Xin Li wrote:
> Hi,
> 
> Currently, FreeBSD does not install a default /etc/ssl/cert.pem
> because we do not maintain one ourselves.  We do, however, provide a
> port, security/ca_root_nss, which have an option to install a symbolic
> link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt,
> which is not the default option.
> 
> This become a problem when applications, e.g. fetch(8), have grown the
> support of doing certificate validation.  I think now it makes sense
> to have a default cert.pem installed with the base system.
> 
> So my proposal would be:
> 
> 1. Import a set of trusted root certificates, and install if
> MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
> 
> 2. In src/etc/Makefile, automatically create a symbolic link if it's
> not already present in ${DESTDIR}/etc/ssl;
> 
> 3. Teach mergemaster(8) and other similar applications to create the
> symbolic link on demand;
> 
> 4. Change the install/deinstall behavior of security/ca_root_nss:
>    ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
> install then overwrite with new symlink, and restore on deinstall.
>    ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
> install new a symlink; on deinstall, if
> /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
> symlink to there, or remove if the file does not exist.
> 
> Comments/objections?
> 
> Cheers,
Please see r266291.

libfetch will now look in /usr/local/etc/ssl/ before /etc/ssl.

The next step was to have the port always install the symlink there.
It's fallen through the cracks though.

This only allows fixing applications that use libfetch though and not
other applications that expect a /etc/ssl/cert.pem like curl. I have no
qualms about making security/ca_root_nss *always* install a symlink into
/usr/local/etc/ssl, but touching base system is not usually proper for a
port. There is this vague idea floating around that for package
building, ports should never touch the base system (except /var/db or
/var/games or /etc/*passwd*) and / should otherwise be read-only. This
has not become a reality or had much discussion yet, though we do frown
on overwriting base and touching base already. For example, the perl
symlink in /usr/bin is phased out.

I like the idea of the base system installing a symlink from
/etc/ssl/cert.pem to *somewhere*.

I like the idea of secteam maintaining a ca-root-freebsd.pem even
better, as long as you are willing to.

IMHO always install it, don't depend on MK_OPENSSL. Is the file actually
specific to OpenSSL? Ports would love to have it be available all the
time regardless of SSL library choices.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140702/b1df48d8/attachment.sig>

On Wed, Jul 02, 2014 at 04:45:53PM -0700, Xin Li wrote:
> Hi,
> 
> Currently, FreeBSD does not install a default /etc/ssl/cert.pem
> because we do not maintain one ourselves.  We do, however, provide a
> port, security/ca_root_nss, which have an option to install a symbolic
> link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt,
> which is not the default option.
> 
> This become a problem when applications, e.g. fetch(8), have grown the
> support of doing certificate validation.  I think now it makes sense
> to have a default cert.pem installed with the base system.
> 
> So my proposal would be:
> 
> 1. Import a set of trusted root certificates, and install if
> MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
> 
> 2. In src/etc/Makefile, automatically create a symbolic link if it's
> not already present in ${DESTDIR}/etc/ssl;
> 
> 3. Teach mergemaster(8) and other similar applications to create the
> symbolic link on demand;
> 
> 4. Change the install/deinstall behavior of security/ca_root_nss:
>    ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
> install then overwrite with new symlink, and restore on deinstall.
>    ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
> install new a symlink; on deinstall, if
> /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
> symlink to there, or remove if the file does not exist.
> 
> Comments/objections?
> 
No objection from me, personally, on the re@ side.  In the longer term,
it would avoid needing to install the security/ca_root_nss port
explicitly for a few things for which they will be needed for 10.1 and
11.0 releases.

I do not, however, believe this is suitable to target for 9.3-RELEASE.

Glen
With hat:   re@

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140702/3f89ef76/attachment.sig>

There is always going to be skepticism about who to trust by default. The CA
system is out of control and it worries me as well. However, if we do not make
an effort to provide a default trust store why do we enforce verification by
default? I feel it would be more consistent to disable verification requiring
those who know what they're doing to create their own trust store and pass
--verify-peer to fetch manually. I'm on the verge of breaking my keyboard
every time I jump onto a random FreeBSD server and try to fetch something over
https.

--no-verify-peer is now muscle memory; that isn't a good sign. I eagerly
await verification through DNSSEC to take off.

-2c

On Jul 2, 2014, at 4:45 PM, Xin Li <delphij at delphij.net> wrote:
> Currently, FreeBSD does not install a default /etc/ssl/cert.pem
> because we do not maintain one ourselves.  We do, however, provide a
> port, security/ca_root_nss, which have an option to install a symbolic
> link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt,
> which is not the default option.
> 
> This become a problem when applications, e.g. fetch(8), have grown the
> support of doing certificate validation.  I think now it makes sense
> to have a default cert.pem installed with the base system.
> 
> So my proposal would be:
> 
> 1. Import a set of trusted root certificates, and install if
> MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
> 
> 2. In src/etc/Makefile, automatically create a symbolic link if it's
> not already present in ${DESTDIR}/etc/ssl;
> 
> 3. Teach mergemaster(8) and other similar applications to create the
> symbolic link on demand;
> 
> 4. Change the install/deinstall behavior of security/ca_root_nss:
>    ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
> install then overwrite with new symlink, and restore on deinstall.
>    ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
> install new a symlink; on deinstall, if
> /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
> symlink to there, or remove if the file does not exist.
> 
> Comments/objections?
It seems like a good plan. As long as people who have a different trust list
than Mozilla can easily implement their own trust plan, it's fine, and this
brings a lot of ease-of-use to the ports, particularly to common ones like wget.

--Paul Hoffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140703/686e5724/attachment.sig>

Xin Li wrote this message on Wed, Jul 02, 2014 at 16:45
-0700:
> 1. Import a set of trusted root certificates, and install if
> MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
My only comment on this is that we (committers) or -core needs to decide
how certs are added/removed... If it's mirror mozzila's cert repo, then
that's fine, but if we don't have a policy, what will we do when other
CA's contact someone at FreeBSD wanting to get their cert included by
default?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

Reviving this discussion because it was never resolved.

Xin Li <delphij at delphij.net> writes:
> Currently, FreeBSD does not install a default /etc/ssl/cert.pem
> because we do not maintain one ourselves.  [...]  So my proposal would
> be:
>
> 1. Import a set of trusted root certificates, and install if
> MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem;
At a minimum, we need the certificate chain for all freebsd.org
certificates.
> 2. In src/etc/Makefile, automatically create a symbolic link if it's
> not already present in ${DESTDIR}/etc/ssl;
>
> 3. Teach mergemaster(8) and other similar applications to create the
> symbolic link on demand;
>
> 4. Change the install/deinstall behavior of security/ca_root_nss:
>    ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on
> install then overwrite with new symlink, and restore on deinstall.
>    ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist,
> install new a symlink; on deinstall, if
> /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a
> symlink to there, or remove if the file does not exist.
I would prefer to have each port install their certificate lists in a
"hidden" location which is then added to the search path using
c_rehash.
This may require changing libfetch and various applications to pass a
path to SSL_CTX_load_verify_locations() instead of or in addition to a
file.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no