Last Comment Bug 422232 - Support new revisions to TLS protocol in PSM, once NSS does
: Support new revisions to TLS protocol in PSM, once NSS does
Status: RESOLVED DUPLICATE of bug 733642
:
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: unspecified
: All All
-- enhancement with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 480514 RFC4346
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-11 14:58 PDT by Chris Evelsizor
Modified: 2013-03-27 11:35 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Chris Evelsizor 2008-03-11 14:58:34 PDT
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
Comment 1 User image Honza Bambas (:mayhemer) 2008-04-30 10:08:57 PDT
Nelson, does NSS supports TLS 1.1 changes? If so, is it switchable to use?
Comment 2 User image Nelson Bolyard (seldom reads bugmail) 2008-04-30 10:52:09 PDT
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.
Comment 3 User image Kai Engert (:kaie) 2010-06-07 07:22:46 PDT
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Comment 4 User image Henrik Pauli 2011-09-20 06:05:03 PDT
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.
Comment 5 User image Neil Harris 2011-09-27 15:02:48 PDT
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?
Comment 6 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-09-27 15:37:48 PDT
(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.
Comment 7 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-03-06 18:46:26 PST
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.
Comment 8 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-03-06 18:47:14 PST
Also, see bug 733647, regarding plans for TLS 1.1 support in Gecko (including Firefox and Thunderbird).
Comment 9 User image anikra 2012-06-18 03:53:20 PDT
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
Comment 10 User image Jo Hermans 2012-06-18 06:28:14 PDT
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
Comment 11 User image Daniel Veditz [:dveditz] 2013-03-27 11:35:50 PDT
(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".

*** This bug has been marked as a duplicate of bug 733642 ***

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