Closed Bug 1721132 Opened 2 years ago Closed 2 years ago

Enabling HTTPS RR on release

Categories

(Core :: Networking, task, P2)

Product:
Core
Component:
Networking
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 92+
firefox92 --- fixed
firefox93 --- fixed

People

(Reporter: kershaw, Assigned: kershaw)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: [necko-triaged])

Attachments

(1 file)

Bug 1721132 - Enable HTTPS RR by default, r=#necko
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

We are about to roll out this feature.

Is this something we should add to the Fx92 relnotes? If so, can you please nominate?

Flags: needinfo?(kershaw)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #1)

Is this something we should add to the Fx92 relnotes? If so, can you please nominate?

Will do. Thanks.

Flags: needinfo?(kershaw)

Release Note Request (optional, but appreciated)
[Why is this notable]: Enabling HTTPS RR allows Firefox to optimize the process of establishing a HTTPS connection.
[Affects Firefox for Android]: Fenix
[Suggested wording]: Enable the two features of HTTPS RR: The first is performing HTTPS upgrade when HTTPS RR is available and the second one is using HTTPS RR as Alt-Svc headers.
[Links (documentation, blog post, etc)]: https://docs.google.com/document/d/1vbxOPjE_jERr0cRNHWiwOLvHyc8UMcDq4_6yZYXNYig/edit?usp=sharing

relnote-firefox: --- → ?
Keywords: dev-doc-needed
Pushed by kjang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/34c9c9b0de17
Enable HTTPS RR by default, r=necko-reviewers,valentin

https://hg.mozilla.org/mozilla-central/rev/34c9c9b0de17

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox93: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

Comment on attachment 9236051 [details]
Bug 1721132 - Enable HTTPS RR by default, r=#necko

Beta/Release Uplift Approval Request

  • User impact if declined: No impact. This uplift is because that we are targeting to enable HTTPS RR on Firefox release 92.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch only contains a pref change.
  • String changes made/needed: N/A
Attachment #9236051 - Flags: approval-mozilla-beta?

Comment on attachment 9236051 [details]
Bug 1721132 - Enable HTTPS RR by default, r=#necko

Approved for 92.0b6.

Attachment #9236051 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Added to the Fx92 beta relnotes:

Firefox now supports automatically performing HTTPS upgrades when HTTPS RR is available and using HTTPS RR as Alt-Svc headers.

This bug has thedev-doc-needed flag against it which has triggered an action for MDN docs: https://github.com/mdn/content/issues/8683

  1. The proposed release note was:

    Firefox now supports automatically performing HTTPS upgrades when HTTPS RR is available and using HTTPS RR as Alt-Svc headers.

    , while the published release note is

    Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

Those two versions sound slightly different. My interpretation would be that the published version is true - i.e. if the browser is able to get an HTTPS RR record it treats this like an Alt-Svc header that had been populated with the equivalent information.
Is that close? If not, what is the distiction between "HTTPS upgrades when HTTPS RR is available" and "and using HTTPS RR as Alt-Svc headers."?
2. What docs were you imagining are needed on MDN?

Flags: needinfo?(kershaw)

(In reply to Hamish Willee from comment #11)

This bug has thedev-doc-needed flag against it which has triggered an action for MDN docs: https://github.com/mdn/content/issues/8683

  1. The proposed release note was:

    Firefox now supports automatically performing HTTPS upgrades when HTTPS RR is available and using HTTPS RR as Alt-Svc headers.

    , while the published release note is

    Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

Those two versions sound slightly different. My interpretation would be that the published version is true - i.e. if the browser is able to get an HTTPS RR record it treats this like an Alt-Svc header that had been populated with the equivalent information.
Is that close? If not, what is the distiction between "HTTPS upgrades when HTTPS RR is available" and "and using HTTPS RR as Alt-Svc headers."?

No, the proposed release note is more accurate than the published one.
There are actually two features of supporting HTTPS RR:

  1. HTTPS upgrades when HTTPS RR is available. Here is what the spec says:
   By publishing a usable HTTPS RR, the server operator indicates that
   all useful HTTP resources on that origin are reachable over HTTPS,
   similar to HTTP Strict Transport Security [HSTS].

So, when Firefox discovers the HTTPS RR is existed for the origin and we are using HTTP to connect to the server, we'll upgrade the connection to HTTPS.

  1. Using HTTPS RR as Alt-Svc. This is about using the information provided in HTTPS RR to optimize the process of establishing HTTPS connection. The concept of this is similar to Alt-Svc header.
  1. What docs were you imagining are needed on MDN?

I am working on a document (more like a blog post) to explain more details and I'll let you know when it is finished.

Flags: needinfo?(kershaw)

@kershaw - thanks, that's great - I've done the necessary docs work in https://github.com/mdn/content/pull/8897. I'm not sure how the concept of this is similar to Alt-Svc header but that doesn't really matter. The point is that the HTTPS RR is useful for two things:

  • optimising setup of (new) HTTPS connections
  • knowing you can safely upgrade from HTTP to HTTPS (merely by its presence).

We'll link from your blog when you create it, but I think this is good enough for now.

You need to log in before you can comment on or make changes to this bug.