search

oracle / ktls-utils

TLS handshake utilities for in-kernel TLS consumers
GNU General Public License v2.0
30 stars 17 forks source link

Remove reverse DNS lookup for peer name #22

Closed bwhacks closed 1 year ago

bwhacks commented 1 year ago

If the kernel provides a peer name that's an IP address, tlshd performs a reverse DNS lookup to turn this into a domain name that can be used for checking against the peer's certificate.

In my testing, when handling the server side of a handshake, tlshd always gets an IP address, does a reverse DNS lookup, but doesn't use the result for checking the client certificate. When handling the client side, it may get an IP address or domain name, depending on how the server was specified in the mount attempt. In this case the domain name, possibly the result of a reverse DNS lookup, is used for checking the server certificate.

The problem with doing a reverse DNS lookup is that this is subject to the same sort of spoofing as any DNS lookup, which is part of what TLS certificates are meant to defend against. I think that attempting to mount from an NFS server specified by IP address, with authenticated TLS, would normally be an error and it should fail rather than invoking this insecure behaviour. Also, it is possible to have a certificate for IP addresses, which currently will be rejected by the client and should work.

chucklever commented 1 year ago

If the kernel provides a peer name that's an IP address, tlshd performs a reverse DNS lookup to turn this into a domain name that can be used for checking against the peer's certificate.

In my testing, when handling the server side of a handshake, tlshd always gets an IP address, does a reverse DNS lookup, but doesn't use the result for checking the client certificate.

This might be a bug. So then, that DNS query is a scalability issue for tlshd when handling SERVERHELLO and should be skipped in that case? Or should tlshd use that DNS query result for something?

When handling the client side, it may get an IP address or domain name, depending on how the server was specified in the mount attempt. In this case the domain name, possibly the result of a reverse DNS lookup, is used for checking the server certificate.

The problem with doing a reverse DNS lookup is that this is subject to the same sort of spoofing as any DNS lookup, which is part of what TLS certificates are meant to defend against.

Various security reviewers have pondered the DNS lookup issue, and have not expressed specific concerns. However we do recognize it's an area that might be improved.

I think that attempting to mount from an NFS server specified by IP address, with authenticated TLS, would normally be an error and it should fail rather than invoking this insecure behaviour.

This as a bug. I'll see what I can do to address it.

Also, it is possible to have a certificate for IP addresses, which currently will be rejected by the client and should work.

This might be an enhancement request. Do you mean we should enable administrators to create server certificates with only an IP address in the SubjectName field? Do you consider that as a common deployment scenario?

bwhacks commented 1 year ago

If the kernel provides a peer name that's an IP address, tlshd performs a reverse DNS lookup to turn this into a domain name that can be used for checking against the peer's certificate. In my testing, when handling the server side of a handshake, tlshd always gets an IP address, does a reverse DNS lookup, but doesn't use the result for checking the client certificate.

This might be a bug. So then, that DNS query is a scalability issue for tlshd when handling SERVERHELLO and should be skipped in that case? Or should tlshd use that DNS query result for something?

I hadn't thought about scalability, but I do think it's not useful.

[...]

Also, it is possible to have a certificate for IP addresses, which currently will be rejected by the client and should work.

This might be an enhancement request. Do you mean we should enable administrators to create server certificates with only an IP address in the SubjectName field? Do you consider that as a common deployment scenario?

I don't think it's at all common practice, and I'm not requesting that you make a specific effort to make them work. The CAB Forum Baseline Requirements do seem to allow it and some people might want to use such certificates, and I would expect them to work if the reverse DNS lookup is removed. But I didn't test this.

chucklever commented 1 year ago

In my testing, when handling the server side of a handshake, tlshd always gets an IP address, does a reverse DNS lookup, but doesn't use the result for checking the client certificate.

The client hostname name is used in log and error messages. This seems harmless, maybe even beneficial, to leave in place for ServerHello.

chucklever commented 1 year ago

I think that attempting to mount from an NFS server specified by IP address, with authenticated TLS, would normally be an error and it should fail rather than invoking this insecure behaviour.

I've reviewed my notes on why we added the reverse lookup behavior for server IP addresses.

So this case is definitely not an error. However, we recognize there is a security risk. I was tasked with coming up with a more secure reverse query mechanism, and that dropped off my plate.

chucklever commented 1 year ago

A brief update: our security expert agrees that the DNS query here is a problem. I'll work with the kernel-tls-handshake group to come up with a set of rules for handling server domain names during mounts, and then try to implement something for ktls-utils 0.10. It very likely won't be consistent with the behavior of Kerberos mounts.

I'm not sure what we will do for pNFS/fs_locations. Probably will need a requirement for the device_addr to contain a netid that matches what's in the client's certificates.

chucklever commented 1 year ago

Closing: The DNS reverse lookup has been removed. Changes will appear in ktls-utils 0.10.