Last Comment Bug 861266 - Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default
: Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default
Status: VERIFIED FIXED
: feature, relnote, sec-want
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: Trunk
: All All
: -- enhancement with 51 votes (vote)
: mozilla28
Assigned To: Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
:
:
Mentors:
http://tools.ietf.org/html/rfc5246
: 932259 943259 (view as bug list)
Depends on: 480514 733647 898431
Blocks: 934663
  Show dependency treegraph
 
Reported: 2013-04-12 10:55 PDT by Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
Modified: 2014-02-13 23:07 PST (History)
155 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
+
verified
27+


Attachments
enable-TLS-1.2-on-aurora.patch (2.62 KB, patch)
2013-11-10 23:46 PST, Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
brian: review+
bajaj.bhavana: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-04-12 10:55:05 PDT
+++ This bug was initially created as a clone of Bug #733647 +++
+++ This bug was initially created as a clone of Bug #565047 +++
Comment 1 ojab 2013-04-12 11:00:27 PDT
URL should be http://www.ietf.org/rfc/rfc5246.txt
Comment 2 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-04-12 11:03:07 PDT
Thanks ojab.
Comment 3 Kalman Kemenczy 2013-06-08 00:33:44 PDT
guys, any update about this?
Comment 4 Neil Turner 2013-06-08 02:45:09 PDT
Patches are being submitted to https://bugzilla.mozilla.org/show_bug.cgi?id=480514 to enable TLS 1.2 on the backend. Once that's done, this should some soon.
Comment 5 rsx11m 2013-06-20 07:14:37 PDT
@Kalman: The patch in bug 733647 would bump security.tls.version.max directly from 1 to 3, thus skipping TLS 1.1 and making TLS 1.2 the default max version.

This bug here will probably close as a duplicate or fixed by the other bug.
Comment 6 Kalman Kemenczy 2013-06-20 07:28:06 PDT
thanks
Comment 7 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-07-07 20:44:03 PDT
In addition to the changes in bug 733647 that enable the TLS 1.2 *protocol*, additional changes are needed to enable TLS 1.2 cipher suites. See "CipherPrefs" in security/manager/ssl/src/nsNSSComponent.cpp for how to do this.

Additionally, our counterparts at Google raninto compatibility issues when they enabled TLS 1.2. The addition of the TLS 1.2 cipher suites caused their client hello message to become larger than 256 bytes, and some servers choke on client hellos larger (or equal?) than 256 bytes. Apparently these servers will simply not respond. Reportedly, https://wellsfargo.com is one such server. So, additional compatibility testing will need to be done.

We should measure how larger our server hello becomes when TLS 1.2 is enabled with the TLS 1.2 cipher suites. If we get close to 256 bytes then we will need to try to figure out if we can trim some cipher suites. For example, we may be able to disable SEED, Camellia, and some DSA cipher suites. And/or we may need to limit which new TLS 1.2 cipher suites we enable.

Because of the compatibility issue with the client hello size, I am not planning to enable the ALPN extension in Gecko until we have things clearly sorted out, because the ALPN extension seems to bloat the client hello size unnecessarily considering that NPN is also an option that every major web browser supports and which many servers support. It is hard to see how the political advantages of ALPN outweigh the technical advantages of NPN and I see little need to support both. But, perhaps the compatibility issues with the large client hello size are not so widespread as to make it an issue in the long term.
Comment 8 Reed Loden [:reed] (use needinfo?) 2013-07-07 21:11:39 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #7)
> Because of the compatibility issue with the client hello size, I am not
> planning to enable the ALPN extension in Gecko until we have things clearly
> sorted out, because the ALPN extension seems to bloat the client hello size
> unnecessarily considering that NPN is also an option that every major web
> browser supports and which many servers support. It is hard to see how the
> political advantages of ALPN outweigh the technical advantages of NPN and I
> see little need to support both. But, perhaps the compatibility issues with
> the large client hello size are not so widespread as to make it an issue in
> the long term.

Just as a heads-up, agl (as per https://www.imperialviolet.org/2013/03/20/alpn.html) plans on ripping NPN support out of Chrome and Google sometime after 2014, swapping completely over to ALPN only.
Comment 9 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-07-08 00:20:34 PDT
mhamrick, please see bug 707275 about the telemetry for cipher suites. We need to start collecting that telemetry ASAP if we're going to make the trade-off of disabling some cipher suites to work around the compatibility issues.

(In reply to Reed Loden [:reed] from comment #8)
> Just as a heads-up, agl (as per
> https://www.imperialviolet.org/2013/03/20/alpn.html) plans on ripping NPN
> support out of Chrome and Google sometime after 2014, swapping completely
> over to ALPN only.

Yes, I am aware. I understand that the Chromium team implemented ALPN first and are now trying to add TLS 1.2, and their TLS 1.2 deployment has been slowed down by the compatibility issues with the large client hello. For us, it will be the opposite: we'll do TLS 1.2 first and then try to figure out if/how we will do ALPN based on the compatibility risk, which is currently unknown. My point is that there is a significant risk that we may not be able to deploy ALPN in Gecko, if it turns out that many servers are intolerant of large client hellos. And, it would be bad for the web if Firefox and Chromium had wildly different cipher suite support and/or different mechanisms for signaling which protocol to speak. It seems like if we just all agreed to use NPN instead then we'd avoid having to trade any useful functionality or risk compatibility

Hopefully, though, the compatibility issues are narrow in scope so that it won't be an issue. Though, I'm not quite sure how we'd become confident of that.
Comment 10 Patrick McManus [:mcmanus] 2013-07-08 05:19:35 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #7)
> 
> Because of the compatibility issue with the client hello size, I am not
> planning to enable the ALPN extension in Gecko until we have things clearly
> sorted out, 

just a heads up that we will need to support ALPN fairly soon (though I am not saying it needs to block tls 1.2) because the IETF TLS WG has asked that it be used to negotiate HTTP/2 instead of NPN... while this relatively recent turn of affairs can be brought back to them, that's the current situation. Its pretty clear there will be an overlap period where we need them both.
Comment 11 Adam Langley 2013-07-08 07:22:59 PDT
Chromium is advertising ALPN and NPN now and the ClientHello size was a problem.

In addition to simply exceeding 256 bytes (I'm not sure whether it's >, or >= 256 that causes issues), one has to worry about the ClientHello with a session ID. Thus the plain ClientHello probably needs to be under 256 - 32 bytes to be safe.

(So far I haven't seen any sites that have issues with large ClientHellos and which issue SessionTickets. I suspect that they don't exist because they wouldn't work.)

In order to trim down our ClientHello size for ALPN and TLS 1.2, I removed a number of ciphersuites. DSS, ECDH, CAMELLIA, SEED and ECC+3DES suites were all removed, save for TLS_DHE_DSS_WITH_AES_128_CBC_SHA in order to keep DSA compatibility.
Comment 12 Kurt Roeckx 2013-07-08 09:08:19 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #7)
> Additionally, our counterparts at Google raninto compatibility issues when
> they enabled TLS 1.2. The addition of the TLS 1.2 cipher suites caused their
> client hello message to become larger than 256 bytes, and some servers choke
> on client hellos larger (or equal?) than 256 bytes. Apparently these servers
> will simply not respond. Reportedly, https://wellsfargo.com is one such
> server. So, additional compatibility testing will need to be done.

We ran into the same issue with openssl.  When it started to do TLS 1.2 there were various sites that had that problem, but all knowns ones were fixed fast.  You could work around this by reducing the number of cipher send.

As far as I know the problem was always with BigIP equipment.  At that time Derek Poon reported this:
| We run a site that uses the F5 Networks BIG-IP load balancer, and
| OpenSSL 1.0.1 triggers this bug on the load balancer.  When it
| occurs, the load balancer neither forwards the request to a pool
| member, nor does it respond to the OpenSSL client.  There are
| warning messages in the load balancer's /var/log/ltm file:

| warning tmm[5313]: 012f0002:4: WARN at ../modules/hudproxy/bigproto/pva/pva_frames.c:1234:Received illegal header padding 100 versus 2ff

| Working with F5 Networks tech support, we have determined that
| this is a known issue, which they track as Bug 376483.  It is
| fixed in the recently released BIG-IP LTM 10.2.4 software, though
| it is not mentioned in their release notes, and I confirm that TLS
| 1.2 connections no longer hang after upgrading to 10.2.4.
Comment 13 Mark Straver 2013-07-14 14:38:09 PDT
Considering bug# 480514 is marked solved and the NSS back-end is done, can we expect this to land in ESR 24? I think it's a rather critical enhancement to land in the ESR branch (often used in corporate environments), since both RC4 and AES-CBC are increasingly insecure.
Comment 14 Kurt Roeckx 2013-07-14 14:41:17 PDT
If you want to get rid of RC4 and AES-CBC, I think want to get bug #880543 fixed.
Comment 15 Florian Bender 2013-07-14 14:46:43 PDT
(In reply to Mark Straver from comment #13)
> Considering bug# 480514 is marked solved and the NSS back-end is done, can
> we expect this to land in ESR 24? 

Given that 24 is already in Aurora, and even TLS v1.1 is not yet implemented (but in progress), this bug will not be fixed in ESR 24.
Comment 16 BoerenkoolMetWorst 2013-09-17 23:19:12 PDT
I still see no target milestone, is there a chance this is going to be fixed soon? The latest versions of Chrome, Opera, Safari and IE11 all have TLS 1.2 implemented AND enabled by default, Firefox is lagging behind.
Comment 17 Johnny Iguna 2013-10-15 02:08:57 PDT
The latest version of Opera, Safari, Chrome and even INTERNET EXPLORER
support TLS 1.1 + TLS 1.2.
Firefox is being left behind, which is rare.
What work needs to be done for TLS 1.2 to be enabled?
Comment 18 Sid Stamm [:geekboy or :sstamm] 2013-10-15 14:37:52 PDT
Camilo: What's left to do?
Comment 19 Camilo Viecco (:cviecco) 2013-10-15 15:57:39 PDT
Sid. This is my understanding of the steps needed (now that 839310 has landed).

1. Wait for patches for 915408 to land in NSS.
2. Patch NSS to allow disabling OCSP Get (there are no psm layer test to verify correctness) (no bug number yet)
3. We need to land in m-c the latest version of NSS (with the previous patches landed)
4. Patch firefox to disable OCSP GET
5. Land in Central
6. Reenable AES-GCM & Enable TLS 1.2 by default (assuming no other issues arise)
Comment 20 Wan-Teh Chang 2013-10-24 19:36:20 PDT
(In reply to Camilo Viecco (:cviecco) from comment #19)
> Sid. This is my understanding of the steps needed (now that 839310 has
> landed).
> 
> 1. Wait for patches for 915408 to land in NSS.

I just landed the patches for bug 915408 in NSS.
Comment 21 Liz Henry (:lizzard) (needinfo? me) 2013-10-29 12:56:20 PDT
*** Bug 932259 has been marked as a duplicate of this bug. ***
Comment 22 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-02 20:56:02 PDT
This is mhamrick's TLS 1.2 patch from bug 733647, rebased on top of the patch for bug 733647:
https://hg.mozilla.org/integration/mozilla-inbound/rev/59401ce2068f
Comment 23 Phil Ringnalda (:philor) 2013-11-03 13:23:42 PST
https://hg.mozilla.org/mozilla-central/rev/59401ce2068f
Comment 24 Nick Lowe 2013-11-10 09:13:21 PST
Is there any chance of making this change for Firefox 27 or will it be for Firefox 28 onwards only?
Comment 25 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-10 13:22:01 PST
(In reply to Nick Lowe from comment #24)
> Is there any chance of making this change for Firefox 27 or will it be for
> Firefox 28 onwards only?

I will ask for it to be uplifted to Aurora 27 very soon.
Comment 26 Kosuke Kaizuka 2013-11-10 15:39:36 PST
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO me if you want a response) from comment #26)
> (In reply to Nick Lowe from comment #24)
> > Is there any chance of making this change for Firefox 27 or will it be for
> > Firefox 28 onwards only?
> 
> I will ask for it to be uplifted to Aurora 27 very soon.

How about Beta 26?
Will Beta 26 have only TLS 1.1 enabled by default (Bug 733647)?
Comment 27 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-10 23:46:07 PST
Created attachment 830048 [details] [diff] [review]
enable-TLS-1.2-on-aurora.patch

[Approval Request Comment]
User impact if declined: No TLS 1.2 in Firefox 27. TLS 1.2 is a pretty high visibility feature (note the votes in this bug and the significant chatter on the net about TLS 1.2). Enabling TLS 1.2 allows us to enable cipher suites that are seen by web server admins as being important to get past recent TLS protocol issues like BEAST, Lucky 13, etc. (Enabling those cipher suites is part of bug 934663.) Enabling TLS 1.2 and the newer cipher suites is important for our upcoming advocacy program to encourage web server developers and (Linux) distributors to enable TLS 1.2 and stronger cipher suites by default. In is unlikely they will be eager to do that until all browsers are shipping TLS 1.2 in release channels. MS, Google, Opera, and Apple are all doing so.

Testing completed (on m-c, etc.): This landed on m-c on 2013-11-03 and we've not had any issues reported during the week. We could use more broad testing and that's why I'm eager to have Aurora users using this. Google is shipping this NSS TLS 1.2 implementation in the current release channel of Chrome, and has been testing it for quite a while on pre-release channels of Chrome. I and other people on the seceng team have been testing TLS 1.2 within Firefox for several weeks and none of us have found any issues.

Risk to taking this patch (and alternatives if risky): Google found some TLS 1.2 compatibility issues, and we (mostly they) have patched up NSS to work around those issues. There is still the possibility that there will be more compatibility issues found. However, the work that landed in NSS 3.15.4 and in bug 839310 (already in mozilla-aurora) should mitigate most compatibility issues.

String or IDL/UUID changes made by this patch: None

I will talk to mwobensmith about additional compatibility testing that QA can do. However, I recommend that we do the uplift to mozilla-aurora now, because the most likely compat issues (captive portals and whatnot) are most likely to be found by having as broad of an audience as possible testing this.

I am not going to try to uplift this to Firefox 26 (currently on the beta channel). I want this to get as much end-user testing as possible. Also, we have a weird schedule for the Firefox 26/27 releases due to the holidays. I want to make sure the enabling of TLS 1.2 goes as smoothly as possible. I recommend people CC'd on this bug set the preference security.tls.version.max=3 in about:config to enable TLS 1.2 on whatever non-ESR version of Firefox they are using. Please report any incompatibilities that you find. Thanks for your help! Note that TLS 1.2 will work on Firefox 25 and Firefox 26 by setting that preference, though those versions of Firefox are missing some of the recent workarounds that were added in response to Google's testing. I've been running Firefox with TLS 1.2 enabled for a very long time without encountering any of those issues, and so have many other people. Give it a shot.
Comment 28 bhavana bajaj [:bajaj] 2013-11-12 21:53:03 PST
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO me if you want a response) from comment #27)
> Created attachment 830048 [details] [diff] [review]
> enable-TLS-1.2-on-aurora.patch
> 
> [Approval Request Comment]
> User impact if declined: No TLS 1.2 in Firefox 27. TLS 1.2 is a pretty high
> visibility feature (note the votes in this bug and the significant chatter
> on the net about TLS 1.2). Enabling TLS 1.2 allows us to enable cipher
> suites that are seen by web server admins as being important to get past
> recent TLS protocol issues like BEAST, Lucky 13, etc. (Enabling those cipher
> suites is part of bug 934663.) Enabling TLS 1.2 and the newer cipher suites
> is important for our upcoming advocacy program to encourage web server
> developers and (Linux) distributors to enable TLS 1.2 and stronger cipher
> suites by default. In is unlikely they will be eager to do that until all
> browsers are shipping TLS 1.2 in release channels. MS, Google, Opera, and
> Apple are all doing so.
> 
> Testing completed (on m-c, etc.): This landed on m-c on 2013-11-03 and we've
> not had any issues reported during the week. We could use more broad testing
> and that's why I'm eager to have Aurora users using this. Google is shipping
> this NSS TLS 1.2 implementation in the current release channel of Chrome,
> and has been testing it for quite a while on pre-release channels of Chrome.
> I and other people on the seceng team have been testing TLS 1.2 within
> Firefox for several weeks and none of us have found any issues.
> 
> Risk to taking this patch (and alternatives if risky): Google found some TLS
> 1.2 compatibility issues, and we (mostly they) have patched up NSS to work
> around those issues. There is still the possibility that there will be more
> compatibility issues found. However, the work that landed in NSS 3.15.4 and
> in bug 839310 (already in mozilla-aurora) should mitigate most compatibility
> issues.
> 
> String or IDL/UUID changes made by this patch: None
> 
> I will talk to mwobensmith about additional compatibility testing that QA
> can do. However, I recommend that we do the uplift to mozilla-aurora now,
> because the most likely compat issues (captive portals and whatnot) are most
> likely to be found by having as broad of an audience as possible testing
> this.
> 
> I am not going to try to uplift this to Firefox 26 (currently on the beta
> channel). I want this to get as much end-user testing as possible. Also, we
> have a weird schedule for the Firefox 26/27 releases due to the holidays. I
> want to make sure the enabling of TLS 1.2 goes as smoothly as possible. I
> recommend people CC'd on this bug set the preference
> security.tls.version.max=3 in about:config to enable TLS 1.2 on whatever
> non-ESR version of Firefox they are using. Please report any
> incompatibilities that you find. Thanks for your help! Note that TLS 1.2
> will work on Firefox 25 and Firefox 26 by setting that preference, though
> those versions of Firefox are missing some of the recent workarounds that
> were added in response to Google's testing. I've been running Firefox with
> TLS 1.2 enabled for a very long time without encountering any of those
> issues, and so have many other people. Give it a shot.

Hey Brian, thanks a lot for the detailed analysis here. Having gone through the bug comments I don't see any critical reasoning for this to jump the trains to be uplifted to Fx27 specifically. Considering the outlined web - compatibility issues that have been stated in this bug, It would be better if this rode the trains and gets a full cycle bake time and be released in Fx28.

Regarding your concern's related to getting testing and exposing this to wider audience, I am in favor of approving the feature to aurora(Fx27) to get more user testing (or even in first two weeks of beta for Fx27) and pref-it off at that point and actually release it with Fx28. Let me know if this is easy to backout/pref-off and the proposed plan sounds good ?
Comment 29 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-12 23:05:59 PST
(In reply to bhavana bajaj [:bajaj] from comment #28)
> Regarding your concern's related to getting testing and exposing this to
> wider audience, I am in favor of approving the feature to aurora(Fx27) to
> get more user testing (or even in first two weeks of beta for Fx27) and
> pref-it off at that point and actually release it with Fx28. Let me know if
> this is easy to backout/pref-off and the proposed plan sounds good ?

Yes, this is very easy to pref off.
security.tls.version.max=3 turns it on,
security.tls.version.max=2 turns it off.

I do think that the proposed plan is reasonable. However, I would still like to leave the door open to this shipping in Fx27 if things are going smoothly, and I think we have all kinds of reasons to expect things to go smoothly. 

Note that during Fx28 we're likely going to land some changes to how our TLS stack works that are going to be riskier than enabling TLS 1.2 is, regarding compatibility. I am a little concerned that if we don't at least try for Fx27, then the decision about whether to ship Fx28 with TLS 1.2 enabled will be more difficult in the event that there are issues with those other changes. I don't want to overstate that concern, because it will be manageable if we can't avoid it; I just want to make you aware that there are risks to NOT shipping TLS 1.2 in Fx27. I will try to attend the next channel/release-drivers meeting to explain some other factors that I can't put in bugzilla.

Regardless, I won't complain if release drivers decide to turn TLS 1.2 off during Fx27 beta.
Comment 30 Roger Lynn 2013-11-13 01:02:58 PST
For reference, TLS 1.2 has been shipping in Seamonkey since 2.21, defaulted to off, but with a user visible option to turn it on.
Comment 31 rsx11m 2013-11-13 06:54:55 PST
Yes, in contrast to Firefox and Thunderbird, SeaMonkey has decided to still make these options available from the preferences for anybody who wants to tweak them. The default is the same as defined in the Core code, thus should change to TLS 1.2 as soon as it's enabled here for the respective channel.
Comment 32 bhavana bajaj [:bajaj] 2013-11-15 11:12:21 PST
(In reply to Brian Smith (:briansmith, was :bsmith; Please NEEDINFO? me if you want a response) from comment #29)
> (In reply to bhavana bajaj [:bajaj] from comment #28)
> > Regarding your concern's related to getting testing and exposing this to
> > wider audience, I am in favor of approving the feature to aurora(Fx27) to
> > get more user testing (or even in first two weeks of beta for Fx27) and
> > pref-it off at that point and actually release it with Fx28. Let me know if
> > this is easy to backout/pref-off and the proposed plan sounds good ?
> 
> Yes, this is very easy to pref off.
> security.tls.version.max=3 turns it on,
> security.tls.version.max=2 turns it off.
great !
> 
> I do think that the proposed plan is reasonable. However, I would still like
> to leave the door open to this shipping in Fx27 if things are going
> smoothly, and I think we have all kinds of reasons to expect things to go
> smoothly.
I don't mind having a conversation again after a few weeks but lets stick to this being the plan for now. I am concerned we might find late breaking regressions too late in the beta cycle if this is not given the deserved baketime. I want to avoid the last minute issues like we hit for OSCP stapling in Fx25, and be more cautious here as web-compat is a concern here.
> 
> Note that during Fx28 we're likely going to land some changes to how our TLS
> stack works that are going to be riskier than enabling TLS 1.2 is, regarding
> compatibility. I am a little concerned that if we don't at least try for
> Fx27, then the decision about whether to ship Fx28 with TLS 1.2 enabled will
> be more difficult in the event that there are issues with those other
> changes. I don't want to overstate that concern, because it will be
> manageable if we can't avoid it; I just want to make you aware that there
> are risks to NOT shipping TLS 1.2 in Fx27. I will try to attend the next
> channel/release-drivers meeting to explain some other factors that I can't
> put in bugzilla.

Sounds good. Channel meeting before the next merge(Dec 9) should be a good one.
> 
> Regardless, I won't complain if release drivers decide to turn TLS 1.2 off
> during Fx27 beta.

:)
Comment 33 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-17 14:28:24 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/5926bf365a2e

(In reply to bhavana bajaj [:bajaj] from comment #32)
> I don't mind having a conversation again after a few weeks but lets stick to
> this being the plan for now. I am concerned we might find late breaking
> regressions too late in the beta cycle if this is not given the deserved
> baketime. I want to avoid the last minute issues like we hit for OSCP
> stapling in Fx25, and be more cautious here as web-compat is a concern here.

FWIW, the big issue with OCSP stapling for Fx25 was actually due to a server-side bug in a popular CDN. Also, OCSP stapling *did* ride the trains without any uplifts. Regardless, I agree that it is worth being careful here. I will work with Matt on improving the compat testing.


> Sounds good. Channel meeting before the next merge(Dec 9) should be a good
> one.

Sure. I will be there.
Comment 34 Florian Bender 2013-11-26 01:08:36 PST
Updating target milestone to clarify tracking. The bug landed in Gecko 28 but was uplifted to Gecko 27.


Please correct if you don't like that.
Comment 35 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-11-26 01:13:46 PST
(In reply to Florian Bender from comment #34)
> Updating target milestone to clarify tracking. The bug landed in Gecko 28
> but was uplifted to Gecko 27.
> 
> 
> Please correct if you don't like that.

Thanks for helping Florian, but we don't use the target milestone that way. We use target milestone to keep track of when it landed in mozilla-central.

You can see above we have "Tracking Flags," and that is where we keep track of uplifts.
Comment 36 Florian Bender 2013-11-26 01:22:06 PST
Alright, noted, sorry about that. I was aiming for correcting https://wiki.mozilla.org/Features/Release_Tracking, but I guess that's less important. 

I filed Bug 943259 for fixing the release notes (intentionally not using the tracking flags in this and the other bug, mostly to make sure this gets into the right notes), that's more important (at least for PR).
Comment 37 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-12-02 12:20:28 PST
*** Bug 943259 has been marked as a duplicate of this bug. ***
Comment 38 Ioana (away) 2014-01-13 02:00:56 PST
Details of testing for Firefox 27 and 28:
https://etherpad.mozilla.org/Fx27b2-TLS-SSL
https://etherpad.mozilla.org/Fx28-0a2-TLS-SSL
Comment 39 Florian Bender 2014-02-03 08:20:53 PST
Please rephrase the relnote to: "Enabled TLS 1.2 by default"

(TLS 1.2 has been implemented a few versions back, it's at least available since Fx 25, maybe even Fx 24 or Fx 23! I don't have the numbers at hand to test. Not fixing this may confuse / lead to bad PR.)
Comment 40 bhavana bajaj [:bajaj] 2014-02-03 12:33:34 PST
Thanks Florain I am going to change to the note  to "Enabled TLS 1.2 and TLS 1.1 by default" and move to to the changed section of release notes, check staging notes(https://www-dev.allizom.org/en-US/firefox/27.0/releasenotes/).
Comment 41 Florian Bender 2014-02-03 13:07:06 PST
Yeah, looks good, thanks! (The relnote flag hasn't been updated, though – don't know if this was intentional, and until the change propagated …)
Comment 42 Michael Kliewe 2014-02-13 17:01:28 PST
Because Thunderbird is mentioned in the title: When will it be enabled by default in Thunderbird?
Comment 43 Magnus Melin 2014-02-13 23:07:23 PST
The next general release is thunderbird31. (If you want betas it's tb27).

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