Firefox 23 will have at least TLS 1.1 support.
It is not known which Firefox version will have TLS 1.2 support.
Note that most browser that support TLS 1.2 may have disabled this because of issues with servers that do not support it and thus can make it impossible to connect to them.

• Bug 733647 - Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default
• Bug 480514 - Implement support for TLS 1.2 (RFC 5246)

(please do not comment in bug reports: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

I agree, but since OpenSSL 1.0.1e supports TLS 1.2, and most important websites do, it's time for Mozilla to raise the bar.

We should not keep reading in the security magazines that drawback for Firefox.....

Firefox 24 (current Aurora) has already supported TLS 1.2 (disabled by default same as TLS 1.1 on Fx 23).

still doesnt work in ff25 (25.0a1 (2013-07-12))

https://www.mikestoolbox.org/ Current time: Fri, 12 Jul 2013 19:40:16 GMT TLS negotiation time: 0.700498 seconds Client Version: TLS 1.0

but internet explorer 10 works: Current time: Fri, 12 Jul 2013 19:41:49 GMT TLS negotiation time: 0.228705 seconds Client Version: TLS 1.2

thats a shame

Hi ololo123, I get an invalid certificate for that site.

According to this bug report, TLS 1.2 requires a couple of different patches and then compatibility testing, so completion is not imminent: Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default.

Note on the bug tracking system: If forum members can contribute to the development, please feel free to pitch in. Otherwise, it's generally not helpful to add comments to bugs (unless there is a call for test cases), but you can register on the Bugzilla site and "vote" for them to be fixed. See:

• Bugzilla Etiquette
• Voting

Surely if the site does not support TLS 1.2, Firefox could step down to TLS 1.1? That would seem to be the best way to handle encryption?

Firefox Nightly 25.0a1

• security.tls.version.max = 3 (TLS 1.2); default is 2 (TLS 1.0)
• security.tls.version.min = 0 (SSL 3.0); default

Test results

• Sites which support TLS 1.2 and below (ex. https://mail.google.com/, https://www.mikestoolbox.org/ ): OK
• Sites which support only TLS 1.1 and below (ex. https://addons.mozilla.org/ ): OK
• Sites which support only TLS 1.0 and below (ex. https://www.startssl.com/ ): OK

As jscher2000 mentioned, neither TLS 1.1 nor 1.2 has not been enabled by default (Bug 733647 and 861266) because of several backward compatibility (Bug 839310 and 861310) and implementation of cipher suite for TLS 1.2 (Bug 707275).

Then have Firefox support all three. What is the big problem?

So from what I've seen here, FF23 is claimed to have TLS1.1 support, but if you activate it, the implementation doesn't allow the server to select a lower protocol version even when you have the min/max protocol controls for the browser set to enable them.

Since RFC 4346 explicitly defines the TLS 1.1 protocol to work this way, its a bit funny to say you have TLS 1.1 support when you have a non-compliant implementation. Not having this feature makes setting TLS 1.1 relatively pointless when it will cause the browser to fail to connect on a significant percentage of all web sites. In other words, your current implementation is pretty unusable.

Your internal settings to control the SSL protocol as a range are exactly what is needed - so I see you have the correct intention and I will assume you are trying to get there as quick as you can. My questions are:

1) What is the defect to actually support the protocol ranges specified and what FF release is it targeted for?

2) There seems to be indications in some responses that TLS 1.2 is supported on some release - can you confirm that? Is it correct that it doesn't allow the server to select a lower protocol if it doesn't support TLS 1.2?

3) If you have TLS 1.2 now, or have it planned, will it offer the clienthello extension for hash and signature algorithms and offer a SHA256 hash? - e.g. is it NIST 800-131a complaint?

4) What cipher suites do you support for TLS 1.1 (and for TLS 1.2 if it is around) and is there a way to control them on the client side? (or at least limit them to a set that has 112 bit security strength for NIST 800-131a compliance)?

I assume you are aware that NIST 800-131a requires 112 bit security strength by 2014 which implies you need SHA-256 signatures which implies you need TLS 1.2 with the client hello extension for hash and signature algorithms with SHA256 hash in the list. This standard will drive a number of folks to scramble for whatever browsers have this support. I'm hoping Firefox is one of them. Thanks in advance for any info...

Hi ric982, last time I researched this, 1.1 was not enabled by default because of the failure to fall back when unavailable. At that time, the developers were working on fixing that. Please check the above link to the bug on 1.2 and see whether it has a reference to the bug(s) for 1.1. You also can search for other TLS bugs on the Bugzilla site. The implementation bugs typically will have the source code attached, and the code comments may answer some of the technical questions better than, say, an old wiki page you might find in a Google search against site:mozilla.org (although that is always a useful thing to try).

Thanks for the replay jscher2000. I'm new here and looks like I need to dig in a bit more. Relative to my (1), I found Bug 839310 and from what I can tell, I guess it's more about dealing within intolerant sites (e.g. try to reconnect using a lesser protocol) than ones that handle negotiating down.

When do they normally fill in the target milestone? (e.g. how and when do they figure out what release it is going in?)

Hi ric982, you wrote:

When do they normally fill in the target milestone? (e.g. how and when do they figure out what release it is going in?)

That I do not know, but it seems to be close to when it goes into the Nightly version.

What about SeaMonkey? It currently supports TLS 1.1. Will it fall back to 1.0 if it has to? I realize this is not a SeaMonkey forum, but I was unable to find a Mozilla SeaMonkey support forum (run by Mozilla).

Hi finitarry,

SeaMonkey has the same backend as Firefox, and Bug 839310 is about core module (not specified to Firefox). So, if this bug is fixed, all Mozilla product (Firefox, Thunderbird, SeaMonkey) will have fallback mechanism.

Thanks.

>> What about SeaMonkey? It currently supports TLS 1.1

Wrong! seamonkey 2.20. Current time: Sat, 24 Aug 2013 05:30:21 GMT TLS negotiation time: 0.692585 seconds Client Version: TLS 1.0

firefox 26.0a1 (2013-08-23) Current time: Sat, 24 Aug 2013 05:42:25 GMT TLS negotiation time: 0.690904 seconds Client Version: TLS 1.0

google chrome 29.0.1547.57 Current time: Sat, 24 Aug 2013 05:45:19 GMT TLS negotiation time: 0.230193 seconds Client Version: TLS 1.2

see, firefox used as "tor browser" to break cenzorship in various countries, all traffic must be encrypted so output node can not decrypt traffic

awful work, your management just dont understand what firefox was and what it should be. you removed all customization, broke user interface. yor developers too dont understand what they doing - your browser still leaks memory. i deinstalled firefox in my organization (70 pc-s, 500 users)

enjoy your Opera-style retirement

Hi olol123,

No.

Firefox 23 / SeaMonkey 2.20 (which uses NSS 3.15) support TLS 1.1, but disabled by default.

Firefox 24+ / SeaMonkey 2.21+ (which uses NSS 3.15.1) support TLS 1.2, but disabled by default.

We can enable TLS 1.1/1.2 by changing security.tls.version.(min|max) values.

(IE 10 on Win8, IE 8-10 on Win7, and Opera 10-12 also support TLS 1.1/1.2, but disabled by default.)

In addition, if you claim Firefox has memory leak, please show us the evidence based on source code. Memory leak cannot be detected by OS memory monitor etc.

just hillarious https://bugzilla.mozilla.org/show_bug.cgi?id=867465 oh, certificate revocation lists are too big, lets delete whole feature instead of embedding recent lists in browser and use ocsp instead

full discussion in https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ilOoDiCU4JM

It seems that it will likely get shipped with either version 27 or 28.

See comments #28 and #29 here: https://bugzilla.mozilla.org/show_bug.cgi?id=861266