Closed Bug 1267631 Opened 4 years ago Closed 3 years ago

Update the SSL/TLS Preference Pane once TLS 1.3 is implemented and ready for prime time

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.48

People

(Reporter: rsx11m.pub, Assigned: rsx11m.pub)

References

Details

Attachments

(2 files)

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

TLS 1.3 implementation is currently underway (bug 1057463 and friends).

Once it's mature enough to be exposed to the public let's add the checkbox to the prefpane.
Assignee: nobody → rsx11m.pub
As discussed yesterday, here the patch adding the "TLS 1.3" label and accesskey.
This should land before the next merge, thus we are flexible with the branches.
Attachment #8746232 - Flags: review?(iann_bugzilla)
This adds the actual checkbox and won't be pushed until the TLS 1.3 core code has been cleared for the releases, when security.tls.version.max is updated at the latest. It also adds TLS 1.3 to the Help description (I didn't touch the example as it's still valid).

I'm not requesting ui-r? as the design was previously approved in bug 1137991.
I can remove the Help portion in case this has to land on comm-beta/release.
Attachment #8747079 - Flags: review?(iann_bugzilla)
(In reply to rsx11m from comment #1)
> Created attachment 8746232 [details] [diff] [review]
> Part I: String additions
> 
> As discussed yesterday, here the patch adding the "TLS 1.3" label and accesskey.
> This should land before the next merge, thus we are flexible with the branches.

Ian, ping for review - work on TLS 1.3 is making swift progress in the related NSS bugs.
As said, this will land first, Part II whenever we want this to become visible in the UI.
Status: NEW → ASSIGNED
Comment on attachment 8746232 [details] [diff] [review]
Part I: String additions [comment #5]

r=me please land the strings
Attachment #8746232 - Flags: review?(iann_bugzilla) → review+
Comment on attachment 8746232 [details] [diff] [review]
Part I: String additions [comment #5]

Thanks, pushed as http://hg.mozilla.org/comm-central/rev/4083a38d6dc8
Attachment #8746232 - Attachment description: Part I: String additions → Part I: String additions [comment #5]
Comment on attachment 8747079 [details] [diff] [review]
Part II: Add the TLS 1.3 checkbox [comment #11]

r/a=me for c-c
If it needs to go onto other branches, put requests in.
Attachment #8747079 - Flags: review?(iann_bugzilla) → review+
I've verified that SeaMonkey 2.47a1 builds with TLS 1.3 enabled, but it's not allowed by default (i.e, security.tls.version.max is 3 = TLS 1.2). I don't have a TLS 1.3 capable server to actually test it.
Flags: needinfo?(philip.chee)
(In reply to rsx11m from comment #7)
> I've verified that SeaMonkey 2.47a1 builds with TLS 1.3 enabled, but it's
> not allowed by default (i.e, security.tls.version.max is 3 = TLS 1.2). I
> don't have a TLS 1.3 capable server to actually test it.

Maybe you can use this: https://tls13.cloudflare.com/
(via) https://blog.cloudflare.com/ietf-hackathon-getting-tls-1-3-working-in-the-browser-2/
Flags: needinfo?(philip.chee)
I have tested a current 2.48a1 build on Linux with https://tls13.cloudflare.com/ and I get a message with the default settings that TLS 1.3 isn't enabled. With security.tls.version.max set to 4, I see a blog (presumably over TLS 1.3). If I also set security.tls.version.min to 4, I still see the blog but all other content from non-TLS1.3 sites throws an error. So, TLS 1.3 works per current draft status.

Switching security.tls.version.max to 4 without any other changes, then browsing conventional https:// websites (including "picky" ones like bank sites) works normally. Thus, enabling TLS 1.3 doesn't seem to have any adverse effects on sites which don't support it yet.

So, intuitively I'd think it's safe to show the checkbox on trunk and then let it ride the train, thus encouraging testing. Since it's disabled by default as of now, the user would have to explicitly go into the SSL/TLS prefpane and enable it, understanding what TLS 1.3 means. Even if enabled by accident, apparently this wouldn't break anything (as long as you don't run into a malicious website which offers TLS 1.3 and exploits any vulnerability).

Let me know what you think and I'll go ahead landing this on comm-central.
Flags: needinfo?(philip.chee)
Flags: needinfo?(iann_bugzilla)
> So, intuitively I'd think it's safe to show the checkbox on trunk and then
> let it ride the train, thus encouraging testing. Since it's disabled by
> default as of now, the user would have to explicitly go into the SSL/TLS
> prefpane and enable it, understanding what TLS 1.3 means. Even if enabled by
> accident, apparently this wouldn't break anything (as long as you don't run
> into a malicious website which offers TLS 1.3 and exploits any
> vulnerability).
> 
> Let me know what you think and I'll go ahead landing this on comm-central.
Sounds good. Please land this.
Flags: needinfo?(philip.chee)
Comment on attachment 8747079 [details] [diff] [review]
Part II: Add the TLS 1.3 checkbox [comment #11]

Thanks, pushed as http://hg.mozilla.org/comm-central/rev/17c160ed79b2
Attachment #8747079 - Attachment description: Part II: Add the TLS 1.3 checkbox → Part II: Add the TLS 1.3 checkbox [comment #11]
Flags: needinfo?(iann_bugzilla)
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.48
TLS 1.3 support has been disabled in Gecko 52 per bug 1342082. If someone sets 1.3 1.2 will used if I interpret the patch correctly. rsx11m do you think the preference should be disabled in 2.49.
Flags: needinfo?(rsx11m.pub)
Meh, yeah - let's back out attachment 8747079 [details] [diff] [review] on comm-beta then, at least the XUL/JS parts...
Do we need a new patch for that?
Flags: needinfo?(rsx11m.pub)
So, this landed on 2.48a1 already, thus would have to be disabled for both c-r and c-b.  :-(
Well FF has its own bug and its a partial backout only so I just created Bug 1342752 for it.
You need to log in before you can comment on or make changes to this bug.