Hi everyone,
On 04/07/2017 23:02, Jan Danielsson wrote:
On 07/04/17 21:15, Benny Siegert wrote:
There are other stories as well, but that's a good illustration of
why it's a bad idea to just hand over a bunch of CA's to users without
any mechanism for keeping the CA database, and CRL's, up to date.
I expected this argument, but it is finally irrelevant. This is because most
users do one of two things:
(a) do nothing and effectively trust all certificates, because none are
installed;
(b) install the mozilla-rootcerts package and trust the mozilla set.
Maybe add
(c) users who consciously select a subset of those certificates — probably a tiny
minority> Compare with root certificates in the base system:
Users in (a) gain cert verification. Users in group (b) do not have to do a
manual step. Users in group (c) lose nothing, because they still can futz with
root certificates manually.
I assert that having a somewhat outdated set of Mozilla’s root certificates is
better than having none at all and implicitly trusting everyone — or worse,
trusting no one and having, say, Mercurial refuse to clone repos over https by
default.
Perhaps, but I think you're mixing two different issues together.
If users choose to disable certificate verification, that's on them.
If TNF takes on the role of a trusted CA source, then that implies a
lot of responsibility that they don't currently have. They can't say
"here, have a bundle of outdated root certificates; we ship them only so
that some programs will shut up." -- that's irresponsible and it's
certain to cause unflattering comments.
Don't take me wrong, I want a solution which would make the X509
experience in NetBSD smoother. But being a trusted CA source means
splotlight and willingness to answer questions if something goes wrong.
I wouldn't be willing to take on that responsibility myself, so I'm not
going to ask TNF to do it. (Though I would obviously be delighted if
they assigned a Chief PKI Officer role and offered a proper CA
distribution solution).
With all that being said, you're not wrong about the complexities of
X509 actually lowering security in many instances, but it's still the
user's choice to do so.
Here's a thing: most users do not have the tiniest clue that there is
such a thing as SSL, even less X.509, certificates or authorities for
that matter.
However, we can go from a default where SSL-based connections never work
(ie can never validate the remote certificate) to a default where those
connections with a trusted CA will be accepted. Even if the list of
trusted CAs is imperfect, it is better than having users decide to never
validate connections, or to use a different OS altogether.
So even though my first reaction to Benny's suggestion would be rather
against it (being a security guy with the associated bit of paranoia) I
think it would be better to ship with certificate authorities, and then
let those savvy users choose to not trust them all by default. Even
then, I do usually prefer the slick experience of the system being easy
to update in case of a security issue, rather than having to toggle the
trust status manually.
Then comes the problem of maintaining and dealing with security issues
regarding these authorities. I can picture two options here:
1. Releasing a security advisory each time, and issuing a new release as
a result.
2. Providing a signed list of trusted CAs that can be updated daily,
much like we do for vulnerable packages.
While the first solution can be very difficult to manage (especially
without a rolling release), it should be possible to fully automate the
second solution, eg with a script running on a TNF machine kept up to
date with pkgsrc's security/mozilla-rootcerts package.
Thoughts?
Cheers,
--
khorben
