Enable OCSP must-staple feature

RESOLVED FIXED in Firefox 45

Status

()

defect
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: briansmith, Assigned: mgoodwin)

Tracking

(Blocks 1 bug)

Trunk
mozilla45
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 fixed)

Details

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #901698 +++

OCSP must-staple requires us to be certain that we do PKIX path building correctly, so this depends on bug 915930.

OCSP must-staple also requires us to be certain that we never fall back to SSL 3.0 for any site that is must-staple, and the work to do that depends on bug 839310 to avoid conflicts.
No longer depends on: 936818

Comment 1

5 years ago
What's still preventing this from being implemented?

Bug #901698 seems to be more about the HSTS-style Must-Staple, not the x509v3 extension. That work seems to be stalled, because it suffers from the first-connection problem or scalability issues if Must-Staple preload lists have to be distributed.

So far it looks like the only thing preventing the x509v3 extension draft from moving forward is the lack of at least one browser implementation. It would be great if we could have such an implementation soon, so that IANA can proceed with OID allocation.

Comment 2

4 years ago
I think the TOFU design is not a problem, but more of an improvement over the current situation of having no real world revocation possible at all. Besides, security minded people are already accustomed to the "pre-load your websites before you travel" pattern because of HSTS.

Supporting a Must-Staple header might also stimulate any progress on the x509 draft, which seem to have been stalled.

According to "Recommendations for Secure Use of TLS and DTLS" section 6.3 (the most recent draft that mentions must-staple):
"The current consensus appears to be that OCSP stapling, combined with
a "must staple" mechanism similar to HSTS, would finally resolve this
problem.  But such a mechanism has not been standardized yet."
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-01#section-6.3

Since the HTTP-header is the most independent and thus fastest way for Mozilla to lead this technology, I hope this will be implemented. Who knows what x509 incentive this might create.

Comment 3

4 years ago
(sorry for spamming, just found out about a thread on IETF of last summer and a new draft)

@briansmith, after the private implementation you've build last summer [1], did you do any more experimenting or implement the most recent draft from last December [2]?

[1] http://www.ietf.org/mail-archive/web/tls/current/msg12785.html
[2] http://www.ietf.org/id/draft-hallambaker-tlsfeature-06.txt
Assignee

Comment 5

4 years ago
Bug 921907 - Enable OCSP must-staple. r?keeler
Attachment #8690032 - Flags: review?(dkeeler)
Assignee

Updated

4 years ago
Assignee: nobody → mgoodwin
Assignee

Comment 6

4 years ago
This time actually running some tests...

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea7f8e3db027
Comment on attachment 8690032 [details]
MozReview Request: Bug 921907 - Enable OCSP must-staple. r?keeler

https://reviewboard.mozilla.org/r/25751/#review23211

I'm not entirely sure why we set this up this way, but yes, let's go ahead and enable it.
Attachment #8690032 - Flags: review?(dkeeler) → review+

Comment 9

4 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/bd02f1cb9f4f
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.