Informally announcing NSS 3.12.5
Nelson B Bolyard
upstream CVS repository with the CVS NSS_3_12_5_RTM.
Sun made NSS 3.12.5 publicly available as a binary patch for some platforms.
See http://sunsolve.sun.com/search/document.do?assetkey=1-66-273350-1
The main reason this release was made at this time was to make available
immediate relief for bug 526689, the recently discovered SSL/TLS
renegotiation vulnerability. See
https://bugzilla.mozilla.org/show_bug.cgi?id=526689
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555
The relief consists of disabling the vulnerable renegotiation feature of
the SSL3/TLS protocol by default in both clients and servers, whether
initiated by the process at the local or remote end of the connection.
A new API has been introduced by which an application can re-enable that
vulnerable renegotiation feature, if desired. Be aware that doing so makes
the application vulnerable again.
There is also a new environment variable that the user/admin may set that
will re-enable renegotiation by default for any process that begins
execution with that environment variable set. This allows the renegotiation
feature to be re-enabled without any program changes, but
again, doing so reintroduces the vulnerability to the attack.
The new environment variable is NSS_SSL_ENABLE_RENEGOTIATION. Setting it to
the value "1" will re-enable renegotiation. Setting it to the value "0"
will leave renegotiation disabled (as it is by default).
Release notes have not yet been published to the web site, but should become
available this week.
The full list of bug fixes and RFEs may be seen at this URL:
Ian G
can you say something about whether & when Firefox will deliver "relief"
for this issue?
My motivation for the question is here:
http://financialcryptography.com/mt/archives/001210.html
iang
On 07/12/2009 10:22, Nelson B Bolyard wrote:
> NSS version 3.12.5 has been released in source code form from the master
> upstream CVS repository with the CVS NSS_3_12_5_RTM.
> The relief consists of disabling the vulnerable renegotiation feature of
> the SSL3/TLS protocol by default in both clients and servers, whether
> initiated by the process at the local or remote end of the connection.
Both, local and remote. OK.
Nelson Bolyard
> Nelson,
>
> can you say something about whether & when Firefox will deliver "relief"
> for this issue?
>
> My motivation for the question is here:
> http://financialcryptography.com/mt/archives/001210.html
Well, first, I must tell you about the plans of the IETF TLS working group
and the plans of NSS for the future of SSL/TLS renegotiation.
The IETF TLS working group is working now on drafting a new improved
standard for "safe renegotiation". The result is expected to offer a way
for a client and server to do renegotiation without vulnerabilities of the
forms that present renegotiation has. It is also expected to offer a way
for a client to tell a server "I no longer do unsafe renegotiation", and
for a server to likewise respond "I no longer do unsafe renegotiation" in
the initial negotiation.
This will enable a client to protect itself from completing a handshake with
an unsafe server, and likewise, will enable a server to protect itself from
completing a handshake with an unsafe client. Only then will a client and
server truly be able to be certain that they are not vulnerable.
Until then, even a client that has disabled renegotiation completely is
vulnerable if it handshakes with an unpatched (and hence unsafe) server,
and likewise, a server that has disabled renegotiation completely is still
potentially vulnerable if it handshakes with an unpatched client. (The
renegotiation MITM attack can work either way. The MITM can "splice"
streams from two clients into an unpatched server, or from two servers
into an unpatched client.)
The relief that NSS has delivered in NSS 3.12.5 is a first phase, interim
relief, until such time as NSS can deliver the new standard for safe
renegotiation and safety signaling. It is hoped that the IETF TLS WG will
finish its work very soon (this month) and that a new NSS release will be
forthcoming also very soon (this month or next).
Now, as to "whether and when" any particular product that uses NSS will
deploy any particular fix, that is up to each individual product to decide
for itself, and those products must speak for themselves. Looking at the
SSL/TLS software industry as a whole, we are seeing an amazing variety of
responses from various vendors, including:
- disabling all renegotiation by default
- disabling renegotiation only in https servers and not in other servers
nor in any clients.
- disabling renegotiation in all servers only, not in clients.
- disabling only client-initiated renegotiation, not server-initiated,
in servers only, or in both clients and servers.
- disabling renegotiation in some versions of SSL/TLS but not others
A number of major software vendors have publicly stated that they believe
their customers will not tolerate ANY reduction in functionality for any
period of time longer than a few hours, vulnerability or not. Some server
vendors seem to genuinely believe that only client-initiated renegotiations
are vulnerable. I would have to summarize what I see as being that software
vendors as a group mostly think their customers (both commercial and
consumers) value security as a distant second to even the most minute
nuances of functionality and convenience, especially in December.
I realize this doesn't directly answer your question. Someone who is truly
empowered to speak for MoCo will have to do that.