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.

Sign up for GitHub

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

Bug: .onion names are no longer prohibited by the Baseline Requirements #440

Closed
sleevi opened this issue May 26, 2020 · 5 comments · Fixed by #450
Closed

Bug: .onion names are no longer prohibited by the Baseline Requirements #440

sleevi opened this issue May 26, 2020 · 5 comments · Fixed by #450
Assignees
@sleevi
Labels
bug new-lint

Comments

@sleevi
Copy link
Contributor

sleevi commented May 26, 2020 •
edited
Loading

lint_san_dns_name_onion_not_ev_cert.go has a lint that returns an error if a .onion name appears in the SAN and the certificate is not EV.

However, as of BRs 1.6.9, with the adoption of CA/Browser Forum Ballot SC27v3, .onion names are now permitted in BR certificates, provided they are subject to additional constraints (differing from the EV Guidelines)

The following tasks are needed:

  • Either Lints can be expanded to support a RetiredDate that is similar to their EffectiveDate, or the EV-only lint be retired to 2020-03-27, the effective date they became permitted by the BRs
    • The effective date may need to be modified, such that it ensures that prior to the effective date, no .onion cert existed (EV or BRs) - that is, it should have been revoked.
    • While if issued after the effective date, but before the retired date, it should be EV.
  • A new lint, for the BRs, to ensure that the label preceeding the .onion address is a:

    "valid Version 3 Onion Address, as defined in section 6 of the Tor Rendezvous Specification - Version 3 located at https://spec.torproject.org/rend-spec-v3"
    as per the BRs, v1.6.9, Appendix C

    • The effective date for this lint would be 2020-03-27
@cpu
Copy link
Member

cpu commented May 31, 2020

Either Lints can be expanded to support a RetiredDate that is similar to their EffectiveDate, or the EV-only lint be retired to 2020-03-27

@sleevi Since this is the first time this has popped up within ZLint (as far as I know) I think I would prefer we update lint_san_dns_name_onion_not_ev_cert.go's checkApplies to check whether the NotBefore is after 2020-03-27. I think we can defer adding a more generalized RetiredDate that way. WDYT? I can't personally commit to implementing much right now and bias towards smaller fixes for the short-term.

@sleevi
Copy link
Contributor Author

sleevi commented May 31, 2020

@cpu Yeah, entirely reasonable! There were definitely lots of ways to solve this, and I wasn’t sure the preference. For example, I wasn’t sure if just making this a “check for rules of .onion” instead (handling both the EV and the DV rules in one lint) made sense.

My assumption was that we should try to separate out lints when EVG and BRGs have separate requirements, or when there are separate dates. Does that match your understanding?

@cpu
Copy link
Member

cpu commented Jun 7, 2020

My assumption was that we should try to separate out lints when EVG and BRGs have separate requirements, or when there are separate dates. Does that match your understanding?

Yup, that sounds ideal to me 👍 Thanks for thinking this through!

sleevi added a commit to sleevi/zlint that referenced this issue Jun 7, 2020
@sleevi
Fix .onion tests to only apply to EV certificates
02a7f11 
Before this change, ZLint would reject .onion names in non-EV certs
via the `lint_san_dns_name_onion_not_ev_cert` lint, and if that
was suppressed, then complain about the missing Tor Service
Descriptor extension. As of CA/Browser Forum Ballot SC27, it's
allowed for v3 onion names to appear in DV/OV/IV certificates, and
the Tor Service Descriptor extension is neither required nor
prohibited for these.

This change corrects the Tor Service Descriptor tests to properly
account for it being mandatory for EV, while optional for DV/OV/IV.
This does not introduce new lints to ensure that the address is
itself a well-formed V2 (if EV) or V3 (all types) address, which
will come in a follow-up change.

Closes zmap#440
@sleevi sleevi mentioned this issue Jun 7, 2020
Merged
@sleevi sleevi self-assigned this Jun 7, 2020
@zakird zakird closed this as completed in 84a8a20 Jun 10, 2020
@sleevi sleevi reopened this Jun 10, 2020
@sleevi
Copy link
Contributor Author

sleevi commented Jun 10, 2020

Just reopening because I incorrectly flagged it as closing, but I split the new lint out (for v2/v3 .onion name well-formedness)

sleevi added a commit to sleevi/zlint that referenced this issue Jun 10, 2020
@sleevi
Lint that .onion addresses are well-formed
57de93c 
Adds a new lint, identified as e_san_dns_name_onion_invalid,
that makes sure that the .onion addresses present within a
certificate are well-formed v2 or v3 addresses, according to
the v2 or v3 Rendezvous specifications.

Closes zmap#440
@sleevi sleevi mentioned this issue Jun 10, 2020
Merged
@cpu cpu closed this as completed in #450 Jun 12, 2020
cpu pushed a commit that referenced this issue Jun 12, 2020
@sleevi
lints: cabf_br lint to verify .onion addresses are well-formed (#450)
d4acbba 
Adds a new lint, identified as `e_san_dns_name_onion_invalid`,
that makes sure that the `.onion` addresses present within a
certificate are well-formed v2 or v3 addresses, according to
the v2 or v3 Rendezvous specifications.

Closes #440
@cpu
Copy link
Member

cpu commented Jun 12, 2020

I split the new lint out (for v2/v3 .onion name well-formedness)

Landed in d4acbba 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sleevi sleevi

Labels
bug new-lint
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Lint that .onion addresses are well-formed sleevi/zlint
2 participants
@cpu @sleevi