tlshd: Kernel should not parse incoming client certificates #122
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NFSD depends on seeing a non-zero remote peerid to know when the new session has been authenticated via mTLS. NFSD does not parse the incoming certificate, but tlshd tries to make it available to the kernel and kernel consumers by adding it to the SPEC keyring. However, add_key(2) /does/ parse the incoming certificate, and any parsing failure results in failure to add the certificate to the keyring. A parsing failure might be the result of an unrecognized (but nonetheless valid) signature encryption algorithm. This will become even more of a hazard as support for PQ signing algorithms is introduced. Key insertion failure causes tlshd to use TLS_NO_PEERID as the remote peer ID. When this happens, a session which is successfully authenticated by GnuTLS looks unauthenticated to NFSD, possibly resulting in rejection of an NFS mount attempt. We don't need or want the kernel or kernel TLS servers to parse incoming certificates, especially now that tlshd is going to set x.509 tags on each session. Replace the add_key(2) call with a fixed special peerid value that indicates successful mutual authentication. This solution is reasonably backward compatible with all existing kernel TLS support. (I suspect the client side is going to have a similar problem). Signed-off-by: Chuck Lever <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NFSD depends on seeing a non-zero remote peerid to know when the new session has been authenticated via mTLS. NFSD does not parse the incoming certificate, but tlshd tries to make it available to the kernel and kernel consumers by adding it to the SPEC keyring.
However, add_key(2) /does/ parse the incoming certificate, and any parsing failure results in failure to add the certificate to the keyring. A parsing failure might be the result of an unrecognized (but nonetheless valid) signature encryption algorithm. This will become even more of a hazard as support for PQ signing algorithms is introduced.
Key insertion failure causes tlshd to use TLS_NO_PEERID as the remote peer ID. When this happens, a session which is successfully authenticated by GnuTLS looks unauthenticated to NFSD, possibly resulting in rejection of an NFS mount attempt.
We don't need or want the kernel or kernel TLS servers to parse incoming certificates, especially now that tlshd is going to set x.509 tags on each session.
Replace the add_key(2) call with a fixed special peerid value that indicates successful mutual authentication. This solution is reasonably backward compatible with all existing kernel TLS support.
(I suspect the client side is going to have a similar problem).