Re: HTTPS trust anchors in sysinst

> Date: Sat, 26 Aug 2023 16:06:39 +0200
> From: Johnny Billquist <[email protected]>
> 
> Even worse - we are then getting into territory where old releases
> might accept bad certificates, since they use SSL and have trust
> anchors and so on. But once those get compromised, these old
> releases/installers are suddenly not safe anymore.

This is not worse than the status quo, which is that the old (and
current!) releases/installers are _already_ not safe from a MITM on
the network when fetching sets over the network from netbsd.org.

> And what about time limits on certificates, and what happens if you
> try to use these installers later? Will they fail, give warnings, or
> just accept that potentially invalid certificates are still being
> used?  With all the trust that gets inferred by this? And if we
> accept potentially bad certificates in the first place, what is the
> point of all this?

I think it is reasonable to expect that if you want to be able to run
a networked installer of an ancient version of NetBSD, you may need to
have to host the sets yourself.

This isn't a new problem with certificates.  ftp(1) in older versions
of NetBSD can't cope with relative `Location' header fields in
redirects, for example.  The URLs for releases older than netbsd-7 (if
I recall correctly) don't work any more -- they've been migrated from
ftp/cdn.n.o to archive.n.o.

But let's suppose, hypothetically, that netbsd-8 had shipped with
mozilla-certdata.  netbsd-8 is almost EOL (within the next two
months), and at over five years I suspect it is one of the longest-
running release branches.  Would it be able to verify the current
cdn.netbsd.org certificate?

That certificate chains back to GlobalSign Root CA - R3, which was
issued in 2009.  By the time NetBSD 8.0 was released (2018-07-17),
GlobalSign Root CA - R3 had already been in mozilla-certdata for
years -- it was added no later than 2013 (but I didn't go further back
in the nss hg history because I hit a file reorganization and chasing
it will be more effort).

So the NetBSD 8.0 installer would still have no trouble working.

It might be vulnerable to MITM on the network with newly compromised
HTTPS CAs since NetBSD 8.0 was released -- but again, that's not a
regression from the status quo which is that it is _always_ vulnerable
to MITM on the network.

> > Also, if you're doing public-key crypto - for anything - in the
> > installers, this will drastically, I am tempted to say
> > catastrophically, slow down installation on low-end machines, like a
> > MicroVAX-II or Sun-3.  (Of course, NetBSD might be fine with that.  I
> > just think it should be at least thought about.)
> 
> It will be worse than horrible...

Can you please follow the same instructions I sent to Mouse to help me
gauge possible performance impacts on the low-end machines you care
about?

https://mail-index.netbsd.org/tech-install/2023/08/27/msg000700.html