Knob: certificates for NTS-KE vs web

[Richard Laager]

On 5/2/22 14:36, Hal Murray via devel wrote:
> I think I've figured out why I think my knob is interesting.
> 
> For the web, there are zillions of clients, most non-technical.  A client is
> likely to connect to many servers, often new/different ones on different days.
>   It all has to just work, straight out of the box.
> 
> For NTS-KE, an at least somewhat technical admin sets things up.  A client
> will only ever contact the few servers that are explicitly configured by the
> admin.  The S in NTS-KE is security.  It seems reasonable to me for the admin
> setting things up, or at least some of them, to be willing to spend a bit of
> time making things more secure.
> 
> My knob is a tiny step in that direction.

Is it a worthwhile step, though?

You're giving me a knob to turn off wildcard acceptance. This presumes 
that the server I'm using isn't using a wildcard certificate; if it is, 
I have to accept the wildcard certificate anyway (or use a different 
server).

So this knob gives me a way, as the client, to ensure that a server that 
is not using a wildcard certificate today doesn't start using one in the 
future. If the server legitimately switched to a wildcard certificate, 
then turning this knob only achieved the result of gratuitously breaking 
my access to that server. But we're trying to protect against attacks, 
so let's focus there.

So this knob gives me a way, as the client, to ensure that a server that 
is not using a wildcard certificate today cannot be MITMed by an 
attacker possessing a non-expired wildcard certificate (from a root that 
I trust) that covers its hostname.

Where would the attacker get such a certificate?

A. A compromised CA

If misissuance is happening at any kind of scale, this should get caught 
by people paying attention to Certificate Transparency logs (discussed 
below), regardless of whether or not ntpd is checking CT logs.

But a compromised CA could just issue a non-wildcard certificate, so the 
knob hasn't helped here.


B. A compromised server at the example.com site that requested and 
approved *.example.com.

Here again, it could just as well have asked for time.example.com or 
whatever.

In fairness, I will admit that request a wildcard certificate once is 
easier, and allows it to be used against as-yet-unknown targets at 
example.com compromised in the future.

On the other hand, sites that don't use wildcard certificates can use 
CAA to prevent issuance of them.


C. A legitimate wildcard certificate from some other server at example.com.

This seems like the most likely scenario.


So this knob gives me a way, as the client, to ensure that a server that 
is not using a wildcard certiciate today cannot be MITMed by an attacker 
who gets a non-expired wildcard certificate from another system at the 
end site.

That's not zero, but it's not some huge thing either. Unless we plan to 
change the default (which is a compatibility risk), how many people are 
ever going to turn that knob? So now we have a small benefit times a 
very small userbase. The code for the knob isn't free; there's bug risk 
and maintenance cost to everything. And this is in a security-sensitive 
pathway (certificate validation).

> The biggest risk that I can see is the root
> server collection that comes packaged with most distros.  We should be able to
> write a script that figures out what cert in the root collection each server
> needs.
You're on the path towards pinning. I'm pretty sure we've discussed that 
before here. In the browser world, pinning seems to have gone out of 
style in favor of Certificate Transparency logs:
https://certificate.transparency.dev/howctworks/
https://en.wikipedia.org/wiki/Certificate_Transparency

Code-wise, I haven't looked in any detail, but this might be a 
reasonable starting point:

https://sites.google.com/site/certificatetransparency/certificate-transparency-in-openssl

To test, I had to do the following:

# Build a ct_log_list.cnf since my distro doesn't provide one
# (grumble grumble)

git clone https://github.com/tiran/ct_log_list.git
cd ct_log_list
make generate
sudo install -m 644 ct_log_list.cnf /etc/ssl/
sudo ln -s /etc/ssl/ct_log_list.cnf /usr/lib/ssl/

# Then I can see that (unsurprisingly) I'm already serving a certificate
# with SCTs.
openssl s_client -connect ntp1.wiktel.com:4460 -ct

So basically, can we make ntpd verify that? That seems like low-hanging 
fruit. We would have to ship an application-specific ct_log_list.cnf to 
cover distros that aren't shipping one.

-- 
Richard