Closed
Bug 1312827
Opened 8 years ago
Closed 7 years ago
make OneCRL only apply to TLS server certificates
Categories
(Core :: Security: PSM, defect, P1)
Core
Security: PSM
Tracking
()
RESOLVED
FIXED
mozilla53
People
(Reporter: keeler, Assigned: keeler)
Details
(Whiteboard: [psm-assigned])
Attachments
(1 file)
59 bytes,
text/x-review-board-request
|
jcj
:
review+
mgoodwin
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details |
When we revoke intermediates in OneCRL, there is the unintended consequence that this also causes email certificates issued from those intermediates to be revoked, reducing their usability in e.g. Thunderbird. One option we have here is to make OneCRL revocations only apply to certificates used in TLS connections.
Comment 1•8 years ago
|
||
If the certificate was revoked, why would it be ok to use as email certificate?
Comment 2•8 years ago
|
||
OneCRL is used to block certain certs, as well as to indicate revoked intermediate certs. OneCRL was designed and implemented for the SSL/TLS use case, so for now we are considering limiting the use of OneCRL to SSL/TLS. If, at some point people who maintain Thunderbird evaluate the S/MIME use cases of OneCRL, and update Thunderbird to address those use cases, then OneCRL may be applied to S/MIME as well. (example use cases: importing certificate, signing email, validating signature on signed email, encrypting email, reading encrypted email)
Comment 3•8 years ago
|
||
What about certificates that are used for other purposes such as content signatures? They're explicitly non-TLS certs but we want to be able to revoke those certs with onecrl iirc.
Comment 4•8 years ago
|
||
As I understand it, OneCRL was intended for TLS certs. Handling S/MIME, code-signing, and content-signing use cases are all reasonable, but I think they should be considered new features. The alternative is to embrace the idea that there's no granular control; that's fine in the event of OneCRL being limited to use for compromise scenarios, but we've already been using it to retire certain TLS trust bits (as opposed to compromise recovery). We'd need to stop that.
Comment 5•8 years ago
|
||
The problem I see is that this would leave everything that's using content signing without a revocation mechanism, e.g. certificates used to update onecrl itself can't be revoked. CS was designed with onecrl as revocation mechanism in mind such that we'd have to reconsider how we use them if onecrl can't be used for revocation anymore.
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → dkeeler
Priority: P2 → P1
Summary: investigate making OneCRL only apply to certificates used in TLS connections → make OneCRL only apply to TLS server certificates
Whiteboard: [psm-backlog] → [psm-assigned]
Comment hidden (mozreview-request) |
Comment 7•7 years ago
|
||
mozreview-review |
Comment on attachment 8821385 [details] bug 1312827 - make the certificate blocklist only apply to TLS server certificates https://reviewboard.mozilla.org/r/100688/#review101224
Attachment #8821385 -
Flags: review?(mgoodwin) → review+
Comment 8•7 years ago
|
||
mozreview-review |
Comment on attachment 8821385 [details] bug 1312827 - make the certificate blocklist only apply to TLS server certificates https://reviewboard.mozilla.org/r/100688/#review101290 Looks good to me, too.
Attachment #8821385 -
Flags: review?(jjones) → review+
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/25d339813371 make the certificate blocklist only apply to TLS server certificates r=jcj,mgoodwin
Assignee | ||
Comment 10•7 years ago
|
||
Thanks! (And, to clarify, we can still revoke content signing certificates with OneCRL - this change only applies to the default certificate verifier, which the content signature implementation actually doesn't use.)
I had to back this out for failures like https://treeherder.mozilla.org/logviewer.html#?job_id=8385621&repo=autoland https://hg.mozilla.org/integration/autoland/rev/23b0e29c4805
Flags: needinfo?(dkeeler)
Comment hidden (mozreview-request) |
Assignee | ||
Comment 13•7 years ago
|
||
Shoot - I had forgotten about that test. The updated patch should address it.
Flags: needinfo?(dkeeler)
Assignee | ||
Comment 14•7 years ago
|
||
Try looked good so I'll give this a go again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=66e27e16d4f0
Comment 15•7 years ago
|
||
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f4001bdf070d make the certificate blocklist only apply to TLS server certificates r=jcj,mgoodwin
Comment 16•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f4001bdf070d
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox53:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Assignee | ||
Comment 17•7 years ago
|
||
Comment on attachment 8821385 [details] bug 1312827 - make the certificate blocklist only apply to TLS server certificates Approval Request Comment [Feature/Bug causing the regression]: OneCRL initially applied to all certificates, not just TLS server certificates [User impact if declined]: this impacts Thunderbird in particular. When we put a certificate in OneCRL, we're saying we don't trust it to issue for TLS server certificates. However, we don't have a similar process and policies for email certificates (for example), so we shouldn't also apply OneCRL to those for the moment. [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: not by QA (although, it does have tests) [Needs manual test from QE? If yes, steps to reproduce]: probably not [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: not very [Why is the change risky/not risky?]: the patch basically adds a single "if" block, and it has tests, so we're pretty sure it's correct and won't cause other problems [String changes made/needed]: none
Attachment #8821385 -
Flags: approval-mozilla-aurora?
Comment 18•7 years ago
|
||
Comment on attachment 8821385 [details] bug 1312827 - make the certificate blocklist only apply to TLS server certificates only look at onecrl for tls server certs, take in aurora52
Attachment #8821385 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 19•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/41dfabec7e72
Updated•7 years ago
|
status-thunderbird_esr45:
--- → affected
tracking-thunderbird_esr45:
--- → +
Comment 20•7 years ago
|
||
Pushed to THUNDERBIRD_45_VERBRANCH https://hg.mozilla.org/releases/mozilla-esr45/rev/5c894801eb1e
Comment 21•7 years ago
|
||
Setting qe-verify- based on David's assessment on manual testing needs (see Comment 17) and the fact that this fix has automated coverage.
Flags: qe-verify-
You need to log in
before you can comment on or make changes to this bug.
Description
•