Closed Bug 861266 Opened 12 years ago Closed 11 years ago

Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla28
Tracking Flags:
Tracking Status
firefox26 --- unaffected
firefox27 + verified
relnote-firefox --- 27+

People

(Reporter: briansmith, Assigned: briansmith)

References

(
URL
)

Details

(Keywords: feature, relnote, sec-want)

Attachments

(1 file)

enable-TLS-1.2-on-aurora.patch
2.62 KB, patch
briansmith
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review
+++ This bug was initially created as a clone of Bug #733647 +++ +++ This bug was initially created as a clone of Bug #565047 +++
URL should be http://www.ietf.org/rfc/rfc5246.txt
guys, any update about this?
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.
@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.
thanks
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.
Assignee: nobody → mhamrick
(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.
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.
Depends on: 707275
(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.
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.
(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.
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.
If you want to get rid of RC4 and AES-CBC, I think want to get bug #880543 fixed.
(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.
Assignee: mhamrick → nobody
Assignee: nobody → brian
Keywords: sec-want
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.
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?
Camilo: What's left to do?
Flags: needinfo?(cviecco)
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)
Flags: needinfo?(cviecco)
(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.
Target Milestone: --- → mozilla28
No longer depends on: 707275
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
https://hg.mozilla.org/mozilla-central/rev/59401ce2068f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Is there any chance of making this change for Firefox 27 or will it be for Firefox 28 onwards only?
(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.
Flags: needinfo?(brian)
(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)?
[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.
Attachment #830048 - Flags: review+
Attachment #830048 - Flags: approval-mozilla-aurora?
Flags: needinfo?(brian)
(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 ?
Flags: needinfo?(brian)
(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.
Flags: needinfo?(brian)
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.
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.
(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. :)
Attachment #830048 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
status-firefox27: affected → fixed
Keywords: verifyme
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.
Keywords: feature
Target Milestone: mozilla28 → mozilla27
(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.
Target Milestone: mozilla27 → mozilla28
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).
Details of testing for Firefox 27 and 28: https://etherpad.mozilla.org/Fx27b2-TLS-SSL https://etherpad.mozilla.org/Fx28-0a2-TLS-SSL
Status: RESOLVED → VERIFIED
status-firefox27: fixed → verified
Keywords: verifyme
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.)
relnote-firefox: 27+ → ?
Flags: needinfo?(bbajaj)
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/).
Flags: needinfo?(bbajaj)
Yeah, looks good, thanks! (The relnote flag hasn't been updated, though – don't know if this was intentional, and until the change propagated …)
Because Thunderbird is mentioned in the title: When will it be enabled by default in Thunderbird?
The next general release is thunderbird31. (If you want betas it's tb27).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: