New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ssl: Enhance client certificate selection #6204
Merged
IngelaAndin
merged 1 commit into
erlang:maint
from
IngelaAndin:ingela/ssl/client-certs/GH-6105/OTP-18191
Aug 16, 2022
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be restricted to only one single cert in the EncodedChain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the assumption I made was that the case where the domain adherence check becomes a problem is when the client is "misconfigured" to only supply its own cert and not the other certs in the chain. As in this case, we cannot perform the check, but the server may be able to verify it anyway (TLS-1.3 spec mandates to try and do that). So in this case we don't really know and it is worth sending what we got. I could send a default always if the check fails, but that kind of makes the check pointless, and the TLS-1.3 spec also says the client SHOULD adhere to the server's auth domain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jjcarstens do you have an actual use case when only part of the chain is supplied? (Root cert can safely be left out).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. We roughly follow the same setup for AWS IOT Client authentication using X.509 Certificates. The server authentication to complete handshake is the same - The device has the certificate chain and includes it in
cacerts
of the request. But the device/client also includes the signer CA used to sign it's device certificate as well which is typically a self-signed and managed CA and also put into thecacerts
request.This signer CA is not required by our server and is only used when the device certificate being presented is unknown (i.e. not pinned in our DB) and is required to be registered with our service first (also like AWS IOT requires registering CA's first). In that situation, we'll run PKIX validation with this signer CA and presented client cert before allowing the connection on the server. If we already know about the client certificate (after looking up its calculated pinned value in the DB), then the signer CA is simply ignored.
It's this extra, unchained signer CA that is getting us with the TLS 1.3 changes. I also don't claim to be an SSL/TLS expert, so it could be that I'm doing things completely wrong and don't fully understand the standards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, TLS-1.3 RFC says this about the extension:
So I think that your use case fits better with having an option to disable the sending of the certificat_authorties extension.
In TLS 1.2 this particular extension is not present but an equivalent value exists sent in the certificate_reques, although the RFC is less clear on how to act, and before it was just ignored, so we let it be backward compatible.