Re: [PATCH 1/7] tlshd_handshake_parms: Dispense with unnecessary dynamic storage for peerids.

[Ken Milmore <ken.milmore@gmail.com>]

On 13/06/2025 22:42, Chuck Lever wrote:
> I think server-side tlshd should /always/ check a client's source IP
> address when IP addresses are listed in the presented certificate's SAN
> field. No new configuration option is needed, I will test to make sure
> all of that is working as we expect.

See my comment below re patch 7 for a possible banana skin.

> The two changes I'm still equivocating on are:
> 
> 1. [PATCH 5/7] server: Add boolean config option "verify_peername" under
>    "[authenticate.server]"
> 
>    I'm not comfortable adding a DNS query. There's no way for tlshd to
>    confirm that the query results are trustworthy, and it will add an
>    indeterminate latency to every handshake.

But note that the existing code already performs a reverse DNS query in order
to obtain a host name from the peer address for logging purposes, so there is
already an indeterminate latency cost.

The forward DNS lookup is a standard practice for increasing the relibility
of a name obtained by reverse lookup, as here. I agree there are ways that
this can be subverted in general cases, but that is true of x.509 with DNS in
general. The present code doesn't perform any additional checks on the
certificate SAN at all.

>    IIRC, tlshd used to perform a query like this, and we were asked to
>    remove it by our security reviewers.

Fair enough, but I would be interested to know where the security risk comes
from. AFAICT, providing a (forward-confirmed) host name for verification against
the certificate can only reduce the scenarios in which the certificate gets accepted,
it cannot increase them. That is to say, if a certificate is rejected by the existing
code without any name check, it will continue to be rejected with the patch applied.
If I'm wrong on this point, I'd be grateful for a citation I can follow up.

The only downside I can think of is that enabling this check may create a false
sense of security (which was never there in the first place), if the admin does
not understand the implications.

That's not to say I don't think that tagging sounds like a better solution,
although given the widest use of x.509 certs is effectively to verify DNS host
names I'm slightly surprised that you don't want to support DNS at all.

Note that the client code *does* already pass the supplied host name to GnuTLS
for verification, so we have a situation where the server name matters on the client
but not vice versa. I was attempting to redress this asymmetry a little.

Checking client names on the server this way will be no good in general internet
situations with NAT, proxies etc (where the client certificate is always likely to
be rejected), but is potentially very useful for adding additional security in a
controlled LAN or VPN situation.

> 2. [PATCH 7/7] client: Add boolean config option "relax_sni" under
>    "[authenticate.client]"
> 
>    I haven't looked closely at this one yet, but I suspect it's
>    nearly the same as the deprecated "-n" option, which was too
>    insecure to be allowed to remain alive.

The documentation for gnutls_server_name_set() states that "IPv4 or IPv6
addresses are not permitted to be set by this function". So if the client
peer address is actually a numeric IP address, surely we should not be calling
this function regardless?

In particular, if you are using certificates with IP addresses in the SAN,
and you are validating those on the server, (as you mention above), I suspect the
certificate will always be rejected regardless of validity. I haven't tested such
cases extensively, so I'm open to correction on this. Once I read the
documentation for gnutls_server_name_set() I realised it should never be given a
hostname containing a numeric IP address regardless of the situation.

> I am working on implementing tagging for x.509 certificates. I found
> other software products that do something similar, so we are on the
> right track with this approach. But it's actually quite a complex
> undertaking, due to the variety of information that can be carried in a
> certificate. Stay tuned.

I really look forward to it!

I'm glad that someone has finally taken this up: A means of securing NFS properly
without Kerberos is *very* long overdue. Was it 15 years or more ago now that
SKPM/LIPKEY was about to be supported but then never made it to fruition? So I
really hope you achieve it this time.

Best wishes,

Ken.