Skip to content
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

Jump to bottom

crypto/x509: Certificate parsing/verification supports non-compliant dNSName constraints #37535

Closed
rolandshoemaker opened this issue Feb 28, 2020 · 4 comments
Closed

crypto/x509: Certificate parsing/verification supports non-compliant dNSName constraints #37535

rolandshoemaker opened this issue Feb 28, 2020 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@rolandshoemaker
Copy link
Member

crypto/x509 supports dNSName name constraints which contain a leading period (i.e. .example.com), which are only valid for URIs per RFC 5280 (a comment in matchDomainConstraint notes this, but implements it anyway). Per #16347 this seems to have mainly been implemented to maintain compatibility with OpenSSL and NSS, which allow these malformed constraints.

The current behavior in Certificate.Verify matches validation of URI constraints, requiring one or more labels to be appended to the name when a leading period is present. Given this is unspecified behavior, per 5280, this should be at least documented somewhere. Depending on the efforts to clarify this behavior (see https://www.rfc-editor.org/errata/eid5997) it may make sense to deprecate support for these constraints altogether (while I'm not sure about prevalence of this misuse in internal PKIs, these constraints are not allowed in the public web PKI).
@cagedmantis cagedmantis added this to the Backlog milestone Feb 28, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 28, 2020
@cagedmantis
Copy link
Contributor

/cc @FiloSottile

@rolandshoemaker
Copy link
Member Author

Just to add a bit of clarity after sleeping on this: I don't think the current behavior is explicitly dangerous as the implementation allows for more restrictive constraints than 5280 specifies. I think the main issue here is that because the behavior is unspecified the expectation of how the constraint should be treated may differ between the user and crypto/x509, which could lead to undesired verification behavior. Hence why I think this should, at the least, be publicly documented.

@gopherbot
Copy link

Change https://golang.org/cl/233525 mentions this issue: crypto/x509: document support for leading periods in DNS constraints

@briansmith
Copy link

Just to add a bit of clarity after sleeping on this: I don't think the current behavior is explicitly dangerous as the implementation allows for more restrictive constraints than 5280 specifies.

I agree with that.

https://www.rfc-editor.org/errata/eid5997

Note that this errata report seems to suggest treating a leading dot the same as when no leading dot is present, which would not have the desired effect. I emailed Ryan about it. I agree with the semantics documented in the CL.

@golang golang locked and limited conversation to collaborators Jun 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@briansmith @cagedmantis @rolandshoemaker @gopherbot