User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4 I just downloaded and installed 3.0 b4 of Firefox. When looking around in settings, I saw that SSL 3.0 and TLS 1.0 are supported. This got me looking around. TLS 1.1 was released as a standard in April 2006 and contains some security improvements: http://www.ietf.org/rfc/rfc4346.txt TLS 1.2 is in draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-09.txt Maybe these (or at least the 1.1) could be added before the browser is released from beta? :) Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A N/A

Nelson, does NSS supports TLS 1.1 changes? If so, is it switchable to use?

No. There is no significant market demand for TLS 1.1, so we've been working on improvements in other areas, such as sharable DBs and full RFC 3280 compliance. Once TLS 1.2 finally becomes an RFC, we will work on that some time thereafter. We believe there will be a demand for TLS 1.2 and some of the new cipher suites that require TLS 1.2 as a prerequisite. The NSS SSL/TLS API by which an application controls the versions of SSL/TLS that it wishes to support may need to be enhanced. There will be some minor PSM changes required, but most of the work will be an NSS enhancement.

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody

I would guess that now that TLS 1.0 and SSL 3.0 have a vulnerability, it might be a good idea to revive this bug and implement (1.1 and) 1.2 support :) Can't let IE get away with it.

As comment 2 above says, "no significant market demand for TLD 1.1", and, as comment 4 says, TLS 1.0 and SSL 3.0 are demonstrably vulnerable to the BEAST proof-of-concept attack (even if would be somewhat difficult to exploit in practice in the wild). Given both of these, would a patch to the TLS 1.0 implementation, by inserting TLS packets with zero-length payloads and random padding, go some mitigate the BEAST vulnerability in TLS 1.0 by effectively randomizing the IV, as a short-term alternative for solving this problem properly in the long run by implementing TLS 1.1/1.2? The Chromium patch for this appears to be very small, and non-invasive: https://src.chromium.org/viewvc/chrome?view=rev&revision=90643 If this is a practical approach for solving the BEAST attack, would it make sense to file a separate bug to implement it?

(In reply to Neil Harris from comment #5) > If this is a practical approach for solving the BEAST attack, would it make > sense to file a separate bug to implement it? Bug 665814.

This is basically a duplicate of bug 733642. I think it is likely that Firefox and other Gecko-based products will support new versions of TLS approximately at the same time NSS adds support for them, and we intend to do as as much as is practical. For example, we will likely have TLS 1.1 support very soon after the TLS 1.1 support in NSS is completed, and we will likely have TLS 1.2 support very soon after TLS 1.2 support in NSS is completed. But, we can't have a blanket policy of supporting the latest version that NSS supports, because there are compatibility issues that have to be considered for each version.

Also, see bug 733647, regarding plans for TLS 1.1 support in Gecko (including Firefox and Thunderbird).

Hi, I have a question? What was the main problem of TLS 1.0 that TLS 1.1 solved and therefore what was the main problem of TLS 1.1 that TLS 1.2 solved?? thank u

Why do you assume that there was a problem ? They're just enhancements to the standard. Different versions of a standard are not 'bug-fixes', even when some of the enhancements might indeed fix a problem in an earlier version. Other enhancements are completely new, or are clarifications to the original standard. If you're referring to the BEAST attack, TLS 1.1 allows the Initialisation Vector to be set explicitly by the application, so it can not be guessed by an attacker. TLS 1.2 has improvements with the hash functions (SHA-256 instead of MD5 and SHA-1). bug 480514 comment 2 http://en.wikipedia.org/wiki/Transport_Layer_Security

(In reply to Brian Smith (:bsmith) from comment #7) > This is basically a duplicate of bug 733642. I agree, and in that light marking this "wontfix" can send the wrong message about our intentions. changing to "dupe".