Bug 189811 - Add various features to base PKI for adding new certs to search paths
Summary: Add various features to base PKI for adding new certs to search paths
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Dag-Erling Smørgrav
URL:
Keywords: feature, needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2014-05-14 18:30 UTC by dreamcat4
Modified: 2017-11-06 09:32 UTC (History)
13 users (show)

See Also:


Attachments
file.txt (526 bytes, patch)
2014-05-14 18:30 UTC, dreamcat4
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description dreamcat4 2014-05-14 18:30:00 UTC
I make this PR because I cannot contact the port maintainer. Tried emailing the "FreeBSD GEKO Team" - geko@freebsd.org. The email bounced, was never delivered.

Problem:

For ca_root_nss there is no /etc/ssl/cert.pem symlink created by default. The PKGNG built pkg of ca_root_nss doesn't create the necessary /etc/ssl/cert.pem file.

Most people think "ah" now i know! i'll just "pkg install ca_root_nss". Yet the result simply does not work. It is infuriating, frustrating, and confusing for newcomers.

No other operating system does this... If i'm on Windows, Mac, Linux, recognizing the ssl certs "just works".

"ca_root_nss" is the only pkg that FreeBSD users are commonly aware of, and will actually install. So it's rather absurd because no alternative or competing SSL cert pkg (that anybody is aware of) is being installed to that same location.

For a "non-default-option", the usualy proceedure to build from ports (manually enabling the ETCSYMLINK option by typing "make config") is also a fail. Because compiling that port pulls in huge perl5 build dependency. For the sake of 1 symlink "ln -s" is utterly absurd - when it can install as pkg instead from pkgng repository.

Fix: Solution:

Make ETCSYMLINK the default build option. Problem goes away.
Patch file included.

Patch attached with submission follows:
How-To-Repeat: pkg install ca_root_nss

Invalid ssl certs.
Comment 1 Edwin Groothuis freebsd_committer 2014-05-14 22:37:50 UTC
Class Changed
From-To: maintainer-update->change-request

Fix category (submitter is not maintainer) (via the GNATS Auto Assign 
Tool)
Comment 2 Edwin Groothuis freebsd_committer 2014-05-14 22:37:52 UTC
Responsible Changed
From-To: freebsd-ports-bugs->gecko

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 3 Jan Beich freebsd_committer 2014-06-25 14:20:16 UTC
gecko@ cannot just decide to trust the provided CA list by default. This needs an approval from secteam as the option affects any base component or port that uses OpenSSL from base.
Comment 4 Simon L. B. Nielsen freebsd_committer 2014-06-25 15:23:54 UTC
I want to point out that this package was explicitly created because secteam / freebsd security officer did not want to vouch for any certificate bundle.

Personally I only think a link like this should be set up after explicitly asking a user if it's OK, while pointing out that there is NO guarantee of the certificates being installed.

Installing the link by default on package install seems like a really bad idea as this package might be pulled in as a dependency in which case a user unknowingly installs a certificate bundle that other programs might pick up.
Comment 5 dreamcat4 2014-06-25 16:12:43 UTC
 would be to have some mechanism, whereby alternative pkg could be installed(In reply to Simon L. B. Nielsen from comment #4)
> I want to point out that this package was explicitly created because secteam
> / freebsd security officer did not want to vouch for any certificate bundle.

Great. Then 3rd party pkgs / ports explicitly aren't part of base, and aren't in the remit of sec team. So you can actually do this (if you wish).

> Personally I only think a link like this should be set up after explicitly
> asking a user if it's OK, while pointing out that there is NO guarantee of
> the certificates being installed.

I'm not sure the vast majority of users agree with such a paranoid stance. The reality is that certs work very well, and have done for quite some time.

OTOH I do agree that it would help if a mechanism to ask such questions were added to pkgng itself. But at this time there is no such alternative.

> … <more security-related paranoia) ...

If indeed there is actually such little confidence in this port, like you are making out, which i really don't believe for a second. Then another way is to give users a choice as to which cert bundle to install. Either this *or* (that conflicts) an alternative pkg/port that does put there the needed /etc/ symlink as it's default setting.

For example: CURL's pre-bundled Mozialla CERTs are from the same source. They may not be updated quite at the same time, i'm not sure. But they are pre-bundled and can just be fetched from the Curl website. One advantage of the CURL certs is that since they are pre-bundled, no need for any Perl Build dependancy. (as unfortunately this port has). Otherwise it wouldn't be such hassle to build ca_root_nss from ports.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2014-06-25 17:06:33 UTC
IMHO, it is sane to say "FreeBSD follows Mozilla's policy w.r.t. to certs and will, by default, trust certs that Mozilla does as well."

This is a little less paranoid than we have said in the past, but makes for a much better user experience.
Comment 7 John Marino freebsd_committer 2014-08-17 19:32:30 UTC
this PR status is set to "Approval Needed".  After reading through it, it seems like it should be reset to "In discussion" or something.  I don't see a pending patch.

(It's showing up a search looking for delinquent approvals)
Comment 8 Xin LI freebsd_committer 2014-08-18 07:03:37 UTC
I have a similar proposal at http://lists.freebsd.org/pipermail/freebsd-security/2014-July/007811.html .
Comment 9 John Marino freebsd_committer 2014-09-04 17:17:21 UTC
Moving to in-discussion.
Comment 10 Conrad Meyer 2014-10-25 15:45:39 UTC
(In reply to John Marino from comment #7)
> I don't see a pending patch.

It's the file.txt attachment.

This is harming real-world security to feed the imaginations of tin-foil-hat paranoids. Users need a sane CA database.

Maybe OpenSSL configuration should include /usr/local/share/certs/ in the default trust DB? If you don't want to trust ca_root_nss certs, don't install it or de-configure that as a search path.
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2014-11-14 01:28:58 UTC
I'm a strong +1 on this.

Additionally, I'd like to see a second symlink created by ca_root_nss, to support the ports version of OpenSSL in addition to the base version, which both use the same default CAFile name in their configuration.

Among many other good reasons to do this, Python has recently moved to verify certificates by default [1][2], which are now causing tests (and runtime functionality) to fail due to the missing root certificates (symlinks).

In order to address the concern regarding the perceived assurance of trust, I believe a post-installation message notifying uses of possible implications and lack of warranty is sufficient.

[1] http://legacy.python.org/dev/peps/pep-0476/
[2] http://bugs.python.org/issue22417
Comment 12 Dag-Erling Smørgrav freebsd_committer 2014-11-15 15:43:49 UTC
Copy-paste from the discussion on freebsd-security@:

Xin Li <delphij@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@des.no
Comment 13 Alfred Perlstein freebsd_committer 2014-11-15 17:26:31 UTC
Is this some joke I am not in on?

Just add the symlink already.  This is completely unacceptable for user experience of FreeBSD.

Not only that, but it actively encourages people to be less secure because they will just use '--disable-cert-check' or whatever command line tool offering disables the check.

The fact that this has been in discussion and still unresolved since May is completely unacceptable and frankly embarrassing.

I will commit this fix in the next 24 hours unless someone has a *real* reason to block this. 

I like Xin's proposal as well and will be fine if he reverts my change when his code is ready for the base system.
Comment 14 Roller 2015-01-01 02:48:05 UTC
I wasn't aware of this until my python scripts started failing recently and I stumbled upon this bug. I've since signed up for this bugzilla and am trying to be more involved.
Comment 15 Alfred Perlstein freebsd_committer 2015-01-02 07:24:00 UTC
+1
Comment 16 Luca Corti 2015-05-13 19:12:07 UTC
+1
Comment 17 Jan Beich freebsd_committer 2015-05-24 18:44:05 UTC
Reset assignee per comment 4. And drop "security" keyword for the issue isn't tied to any (potential) vulnerability.
Comment 18 Dag-Erling Smørgrav freebsd_committer 2015-06-02 08:38:00 UTC
The symlink was added to the ca_root_nss port in r378720 on 2015-02-09, as a stopgap measure.  I still stand by what I wrote in comment 12 and will try to implement this during the summer.
Comment 19 Kubilay Kocak freebsd_committer freebsd_triage 2015-06-02 11:00:42 UTC
(In reply to Dag-Erling Smørgrav from comment #18)

As you're probably aware, my commit in 378720 only covered OpenSSL from ports (which looks in the LOCALBASE location). It did not cover OpenSSL in *base* for consuming software using the SSL_CTX_load_verify_locations function.

ETCSYMLINK still needs to be turned on as a default option (the intent and spirit of this issue) in the short-term until we have the infrastructure in place to do better or with greater granularity

I was just about to assign this issue to myself for resolution, so if you'd like to re-assign it, we can create a separate issue for the additional implementation
Comment 20 Dag-Erling Smørgrav freebsd_committer 2015-06-02 14:32:06 UTC
@koobs I suggest you just commit the ETCSYMLINK change and leave the bug assigned to me.
Comment 21 Kubilay Kocak freebsd_committer freebsd_triage 2015-06-02 14:32:57 UTC
(In reply to Dag-Erling Smørgrav from comment #20)

Roger that, stand by.
Comment 22 commit-hook freebsd_committer 2015-06-06 07:42:09 UTC
A commit references this bug:

Author: koobs
Date: Sat Jun  6 07:41:52 UTC 2015
New revision: 388657
URL: https://svnweb.freebsd.org/changeset/ports/388657

Log:
  security/ca_root_nss: Enable certificate verification (for Base OpenSSL)

  Enable the ETCSYMLINK option so that SSL certificate verification is
  enabled by default for OpenSSL in base.

  This change is the third in a set of changes [1][2] that improves the
  default configuration and behaviour of client software relying on
  OpenSSL for SSL/TLS and certificate verification.

  A symlink is installed which points to the root certificate bundle in
  the location that OpenSSL in base looks for them, as configured at build
  time [2].

  This allows any and all software utilising SSL_CTX_load_verify_locations
  function to verify SSL certificates by default after installation of
  this package.

  [1] https://svnweb.freebsd.org/changeset/ports/372629
  [2] https://svnweb.freebsd.org/changeset/ports/378720

  PR:		189811 196357
  Requested by:	many
  Submitted by:	dreamcat4 gmail com
  Approved by:	maintainer timeout (>1 year)

Changes:
  head/security/ca_root_nss/Makefile
Comment 23 Kubilay Kocak freebsd_committer freebsd_triage 2015-06-06 07:45:39 UTC
No longer blocking bug 196357.

This issues summary now requires changing  to account for the additional changes and extensions to certificate infrastructure going forward.

@des, please update the summary according to your needs.
Comment 24 Michael Osipov 2016-06-24 11:00:31 UTC
I can say that this works really nice. Why is this ticket still open?
Though, I do not understand who copies /usr/local/openssl/cert.pem. The Makefile has no copy command. Can someone enlighted me?
Comment 25 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-24 11:07:14 UTC
This issue was left open to continue on to possible base PKI features mentioned in comment 12 and comment 14. It should have instead be closed, given the issue as originally reported, has been resolved.

Given no movement, reass0gin to me given I committed the change that added support for base OpenSSl to see ca_root_nss certificates. 

Any features relating to extending base PKI should be created in new issues
Comment 26 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-24 11:08:26 UTC
"Comment 14" was supposed to read Comment 18.

See also comment 20
Comment 27 Dag-Erling Smørgrav freebsd_committer 2016-06-24 20:26:22 UTC
By all means, let's just shove the entire discussion under a rug just because a temporary solution was committed.
Comment 28 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-25 02:47:16 UTC
(In reply to Dag-Erling Smørgrav from comment #27)

Sarcasm is not necessary, please keep discussions on the issue tracker civil and respectful.

Closing the issue is not an attempt to hide anything under a rug, as was explained in comment 25 and more explicitly below:

1) The issue was resolved as per original report (and summary)
2) No changes were made to reflect the future intent of the issue for 1 year
3) Related but separate issues that arise out of discussion on a bug should be tracked in separate (possibly dependent) issues to avoid ambiguity of who is/was involved, in what and when.

Having said that, in order to avoid continuation of a bug re-assignment war, I will update this summary of, and re-categorize the issue for you so it reflects what is intended now.