Bug 533125 (CVE-2009-3555)

Summary: CVE-2009-3555 TLS: MITM attacks via session renegotiation
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aca21, ahughes, bkearney, brucetim, ccsadmins, cfb, ckannan, cpelland, dbhole, degts, elliot, emaldona, eren, extremoburo, flint42, hauser, ijc, james.brown, jlieskov, jorton, jrusnack, jvanek, katello-bugs, kengert, kreilly, liko, mmccune, mschoene, nelson, Nicholas.Hawkins.ctr, pbat, pnewell, randrews, rayvd, rcritten, rrelyea, shaines, sputhenp, tao, tech, tjay, tmraz, uwe.knop, vdanen, wnefal+redhatbugzilla, youngad6
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20091105,reported=20091002,source=phonefactor,cvss2=4.3/AV:N/AC:M/Au:N/C:N/I:P/A:N,cwe=CWE-300,rhn_satellite_6/pulp=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-07 06:30:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 230399, 534038, 534039, 534040, 534041, 534042, 534086, 534088, 537839, 538750, 539573, 543534, 543535, 543536, 543537, 547448, 559000, 559704, 560680, 560681, 563125, 563127, 565556, 565557, 565562, 565563, 565564, 565565, 565580, 565581, 565584, 565585, 566508, 567917, 567918, 568670, 570843, 570844, 570845, 573653, 573658, 573659, 576124, 576125, 576533, 578421, 582839, 583817, 589514, 589515, 639951, 639952, 639953, 639954, 642515, 642517, 643336, 643337, 643338, 643355, 643356, 643357, 646406, 646407, 646408, 662638, 662639, 662640, 673086, 805159, 813717, 978409, 1127896, 1174942    
Bug Blocks: 712887, 978671    
Attachments:
Description Flags
NSS patch to turn off renegotiation
none
Keep SSL_RENEGOTIATE_TRANSITIONAL as the default value none

Description Tomas Hoger 2009-11-05 03:26:58 EST
Marsh Ray of PhoneFactor has discovered a flaw in the TLS/SSL protocol related to the handling of the session rehandshakes / renegotiations.  This flaw can possibly be used in the MITM attacks and allowing an attacker to inject attacker-chosen plain text prefix to the session of the victim.

Further details are available in the "Authentication Gap in TLS Renegotiation" blog post:
  http://extendedsubset.com/?p=8
Comment 1 Tomas Hoger 2009-11-05 03:43:03 EST
Independent discovery by Martin Rex:
  http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
Comment 2 Tomas Hoger 2009-11-05 03:49:34 EST
Ben Laurie's blog post with proposed change for OpenSSL:
  http://www.links.org/?p=780

Note: This workaround disables all renegotiation, so it will break all uses where renegotiation is required and used.
Comment 3 Tomas Hoger 2009-11-05 04:06:46 EST
Proposed patches for GnuTLS from PhoneFactor:
  http://lists.gnu.org/archive/html/gnutls-devel/2009-11/msg00014.html
Comment 4 Tomas Hoger 2009-11-05 07:56:41 EST
(In reply to comment #2)
> Ben Laurie's blog post with proposed change for OpenSSL:
>   http://www.links.org/?p=780

Committed now in OpenSSL CVS too:
  http://cvs.openssl.org/chngview?cn=18790

Applications shipped in Red Hat Enterprise Linux that are likely to be negatively impacted by this change:

- mod_ssl - Server-initiated renegotiations are commonly needed in setups where client certificate authentication is required for some parts of the web site, but not for the whole site, or when different cipher suites are required for different parts of the site.

- PostgreSQL - Server initiates renegotiation after certain amount of data was transferred through the connection.
Comment 6 Bob Relyea 2009-11-05 19:12:04 EST
Mozilla bug for NSS is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=524596

It's security sensitive. Bob Relyea, Kai Engert and Eli Maldanado can now read the bug. If you have a mozilla bugzilla account I can add you as well.

There are a set of patches which turn off renegotiation.

bob
Comment 7 Bob Relyea 2009-11-05 19:43:37 EST
Wrong mozilla bug. Here's the correct one:
https://bugzilla.mozilla.org/show_bug.cgi?id=526689

bob
Comment 9 Vincent Danen 2009-11-05 20:36:00 EST
To stave off any questions or inquiries regarding openssh, there is this official heads up regarding openssh _not_ being affected by this:

http://djm.net.au/2009/11/6/ssh-is-not-vulnerable-to-the-ssl-tls-mitm-attack
Comment 10 Bob Relyea 2009-11-05 21:12:13 EST
Created attachment 367773 [details]
NSS patch to turn off renegotiation

This is still a preliminary patch. There is still more testing needed on it.
Comment 11 Bob Relyea 2009-11-05 21:20:31 EST
Once the official patch is ready, it should land in the NSS public source tree.

bob
Comment 12 Tomas Hoger 2009-11-06 05:04:25 EST
(In reply to comment #4)
> Committed now in OpenSSL CVS too:
>   http://cvs.openssl.org/chngview?cn=18790

OpenSSL 0.9.8l was released that disables all renegotiations by default:

  http://marc.info/?l=openssl-dev&m=125744015832463&w=2

(Modified) Applications may re-enable renegotiations at runtime.

Relevant upstream commits:
  http://cvs.openssl.org/chngview?cn=18791
  http://cvs.openssl.org/chngview?cn=18794
  http://cvs.openssl.org/chngview?cn=18795
Comment 13 Tomas Hoger 2009-11-06 05:32:25 EST
Fairly good blog post from Eric Rescorla explaining the flaw in greater detail as well as describing impact:
  http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

More details on the implication of the flaw for HTTP documented in Chris Paget's blog:
  http://www.tombom.co.uk/blog/?p=85

Chris explains that there are other well-known ways to forge crafted GET / POST requests authenticated using victim's cookies or client certificate - CSRF attacks.  For MITM attacker, standard CSRF attack may be even easier to mount, as it can be done by adding malicious links or javascript to any HTTP page requested by the victim.  Proper CSRF protections should block attacks via TLS MITM.  Normal CSRF attack, however, may be easier to spot by victim where client certificates are used and each certificate use must be acknowledged by user (default configuration in e.g. firefox), as prompt for certificate use will appear in unexpected moment.
Comment 14 Tomas Hoger 2009-11-06 05:55:06 EST
Red Hat Knowledgebase article:
  http://kbase.redhat.com/faq/docs/DOC-20491
Comment 15 Tomas Hoger 2009-11-06 10:39:56 EST
(In reply to comment #10)
> Created an attachment (id=367773) [details]
> NSS patch to turn off renegotiation

Reading the patch and upstream bug report, this allows enabling or disabling renegotiation and making a space for adding the "handle reneg extension" when RFC / implementation is ready.  Will that allow servers to tell NSS to ignore all server-initiated renegs completely?

I'm also marking that attachment obsolete, upstream bug has updated version of it already.
Comment 16 Bob Relyea 2009-11-06 13:11:33 EST
The current patch either turns off all renegotiation, or turns on all renegotioation. There is currently no way to turn off just client initiated renegotiation, and I don't expect one from upstream anytime soon.

The 'space' is for implementing the tls reneg extension draft. So as the end result would be the following options:

no renegotiation -- ever. (client or server)
renegotiate only if the extension is in use.
allow any type of renegotiation.

It's probably reasonable to add an option that says 'no client renegotiation'. 

All on or all off would help most customers immediately, so it seems reasonable to get those out to them.

bob
Comment 20 Rick Andrews 2009-11-10 18:31:54 EST
Turning off all renegotiation means that SGC step-up will not happen. There are a lot of SGC certs out there, and browsers that can perform step-up. I hope that a better patch gets developed that allows renegotiation but cryptographically ties together the two sessions.

-Rick Andrews
Comment 21 Bob Relyea 2009-11-10 18:54:07 EST
There are very few browsers out there that need to do SGC step-up anymore. Browser companies have been shipping full strength clients since 2001. Step-up requires client initiated renegotiation, which has been turned of in IIS for a while now.

There are plans to re-enable renegotiation with an extension being discussed in the tls working group, and patches are being worked on, but its extremely unlikely that anyone with a browser that is so old that it needs to do ssl step-up will be able to get a patch that fixes that browser to do a safe renegotiation.
Comment 22 Rick Andrews 2009-11-10 19:37:09 EST
Bob,

I understand that if the fix requires changes to both browser and web server, then it's unlikely that very old browsers will get patched. But if a fix can be done on the server without browser changes, then I would hope that it would be done in such a way as to allow old browsers to continue to work (unlike the current approach of simply turning off renegotiation).

-Rick
Comment 23 Tomas Hoger 2009-11-11 04:17:06 EST
A mitigation patch was created for mod_ssl, which rejects all client-initiated renegotiation requests:

http://marc.info/?l=apache-httpd-announce&m=125755783724966&w=2
http://svn.apache.org/viewvc?view=revision&revision=833622
http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch

This change is planned to be included in the upcoming httpd updates.

It resolves the problem for majority of HTTPS sites, but does not completely resolve the issue in deployments where server-initiated renegotiations are used (client certificates or different cipher suites required for some parts of the web site, but not required on the initial connection, see comment #4).
Comment 24 Joe Orton 2009-11-11 04:43:05 EST
Rick -

We looked into SGC last week but weren't be totally sure about what happens - my reading of the OpenSSL code indicated it might be OK.

I've now found a description of the SGC protocol in EKR's book.  The "Step-Up" protocol will not work with the patched server (at least mod_ssl) because it requires a renegotiation.  The "SGC" protocol is different; in that case the client never completes the first handshake, but simply starts a new one with a new ClientHello after receiving the ServerHello with a cert advertising SGC support.

As far as I can tell that should still work with the patched server.  If someone from a friendly CA could give us an SGC test cert we might be able test it out ;)
(generating a test cert looked to be hard because the browsers restrict SGC support to specific CA roots)
Comment 25 Tomas Hoger 2009-11-11 05:56:21 EST
Unlike OpenSSL or NSS, GnuTLS does not handle renegotiation transparently for applications.  GNUTLS_E_REHANDSHAKE error code is returned instead requiring application to handle the renegotiation.  There are currently no known server applications using GnuTLS that have renegotiation handling implemented.  For further details, see the discussion on the gnutls-dev mailing list:

http://lists.gnu.org/archive/html/gnutls-devel/2009-11/msg00043.html
Comment 26 Rick Andrews 2009-11-11 12:42:17 EST
(In reply to comment #24)
> As far as I can tell that should still work with the patched server.  If
> someone from a friendly CA could give us an SGC test cert we might be able test
> it out ;)
> (generating a test cert looked to be hard because the browsers restrict SGC
> support to specific CA roots)  

Joe,

We're a friendly CA :^) If you give me a CSR for a domain you own, I'll get an SGC cert issued for you. We'll probably want to pre-date it so that it's already expired when you get it, but you can work around that by simply moving clocks back.

-Rick
Comment 27 Tomas Hoger 2009-11-11 12:43:58 EST
(In reply to comment #12)
> OpenSSL 0.9.8l was released that disables all renegotiations by default:
>   http://marc.info/?l=openssl-dev&m=125744015832463&w=2

Related OpenSSL Security Advisory:
  http://www.openssl.org/news/secadv_20091111.txt
Comment 28 errata-xmlrpc 2009-11-11 17:09:36 EST
This issue has been addressed in httpd packages in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1580 https://rhn.redhat.com/errata/RHSA-2009-1580.html
Comment 29 errata-xmlrpc 2009-11-11 17:09:43 EST
This issue has been addressed in httpd packages in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 3

Via RHSA-2009:1579 https://rhn.redhat.com/errata/RHSA-2009-1579.html
Comment 30 Tomas Hoger 2009-11-12 03:23:14 EST
RHSA-2009:1579 and RHSA-2009:1580 do not fully resolve the issue for HTTPS using httpd / mod_ssl, but only add mitigation patch described in comment #23. Configurations that require server-initiated renegotiations are still vulnerable.
Comment 32 Tomas Hoger 2009-11-12 05:04:07 EST
US-CERT Vulnerability Note VU#120541 covering this flaw:
  http://www.kb.cert.org/vuls/id/120541
Comment 33 Tomas Hoger 2009-11-12 10:19:47 EST
This issue was confirmed in Java Secure Socket Extensions (JSSE) provided with JREs/JDKs, see e.g.:
  http://blogs.sun.com/security/entry/vulnerability_in_tls_protocol_during

Client-requested renegotiations are handled automatically by JSSE.  Verified with Sun, IBM and OpenJDK JREs.
Comment 36 Tomas Hoger 2009-11-18 10:15:20 EST
PhoneFactor status tracking page:
http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches
Comment 37 Tomas Hoger 2009-11-18 11:59:47 EST
Answers to some frequently asked questions:


Can renegotiation be disabled for OpenSSL / NSS?

No, current versions do not provide a way to disable renegotiations
without modifications of the library, or applications using it (as was
done for mod_ssl).


New OpenSSL version 0.9.8l was released disabling all renegotiations.
There's no official Red Hat update providing similar fix available at
the moment.  Why?

There are several reasons for that:
- Upstream fix disables all renegotiations even though it is known to
  break valid uses where renegotiations are required (e.g. certain 
  mod_ssl setups).  That is clearly stated in the "Workaround" section
  of the OpenSSL advisory:
  
  http://www.openssl.org/news/secadv_20091111.txt
  Servers that need renegotiation to function correctly obviously cannot
  deploy this fix without breakage.
  
- Upstream fix in 0.9.8l does not provide a way to re-enable
  renegotiations without modifying application.  Post-0.9.8l versions
  even use different way to re-enable renegotiations.
  
- Upstream fix introduces unexpected behavior in some cases, client
  renegotiation request is never replied by the server instead of
  causing the server to report handshake failure.
  
Due to these reasons, we do not plan to use patch included in 0.9.8l in
the Red Hat Security Advisories.


Does Red Hat plan to release NSS update that disables all renegotiations?

We're considering this.  Unlike OpenSSL, NSS has a tradition of using
environment variables to control its features.  Therefore, it's 
possible to disable renegotiations by default and re-enable them only
for certain applications via certain environment variables. 


Is there any time line for the final fix?

Unfortunately, there's no fixed time line for the final fix
implementing TLS renegotiation extension.  The extension is still being
discussed by the IETF TLS working group and its implementations are in
progress.
Comment 38 Tomas Hoger 2009-11-19 15:20:22 EST
Similar mitigation fix as mention for mod_ssl in comment #23 was applied in tomcat-native SVN:
  http://svn.apache.org/viewvc?view=revision&revision=835322
  http://svn.apache.org/viewvc?view=revision&revision=835335
Comment 40 Vincent Danen 2009-11-27 16:19:26 EST
The patch for nginx is here: http://sysoev.ru/nginx/patch.cve-2009-3555.txt
Comment 42 Nelson Bolyard 2009-12-04 16:40:55 EST
In reply to comment 23:
> A mitigation patch was created for mod_ssl, which rejects all 
> client-initiated renegotiation requests:

Given that Marsh Ray's attach works equally well with client-initiated 
renegotiations and server-initiated renegotiations, why is it thought 
that disabling only client-initiated renegotiations is an effective 
mitigation to this vulnerability?
Comment 43 Joe Orton 2009-12-07 07:47:48 EST
(In reply to comment #42)
> Given that Marsh Ray's attach works equally well with client-initiated 
> renegotiations and server-initiated renegotiations, why is it thought 
> that disabling only client-initiated renegotiations is an effective 
> mitigation to this vulnerability?  

The patch deployed will fix the vulnerability for any configuration which does not require server-initiated renegotiation.  The majority of mod_ssl configurations do not require server-initiated renegotiation.   This is described in the erratum text referenced above:

https://rhn.redhat.com/errata/RHSA-2009-1579.html

The upstream discussion thread on this topic is here, for reference:

http://markmail.org/thread/jmpsjhz3fy6mivv3

Once the new "safe" renegotiation protocol is published, and OpenSSL is updated to support it, I expect to be able to flip the mod_ssl default to "secure by default", with a config option to allow "unsafe" renegotiation.
Comment 45 Marc Schoenefeld 2009-12-10 05:11:32 EST
CVE-2009-3555 affects Tomcat if connectors are configured that use a vulnerable TLS implementation.  

The APR connector relies on OpenSSL, and is vulnerable if the version of OpenSSL is vulnerable.

NIO (non-blocking IO) and BIO (blocking IO) connectors use the JSSE implementation of the underlying JRE. 

The NIO connector is not affected, as it does not support renegotiation.

To workaround the vulnerability within tomcat until a fix for JSSE is available, the BIO connector configuration offers a "allowUnsafeLegacyRenegotiation" attribute from Tomcat 6.0.21 onwards. The default value "false" protects against the vulnerability. 

http://tomcat.apache.org/security-5.html#Not%20a%20vulnerability%20in%20Tomcat
http://tomcat.apache.org/security-6.html#Not%20a%20vulnerability%20in%20Tomcat
Comment 46 Fedora Update System 2009-12-27 15:23:52 EST
proftpd-1.3.2c-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 47 Fedora Update System 2009-12-27 15:34:38 EST
proftpd-1.3.2c-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 48 errata-xmlrpc 2010-01-06 11:21:10 EST
This issue has been addressed in httpd packages in following products:

  JBEWS 1.0.0 for RHEL 4
  JBEWS 1.0.0 for RHEL 5

Via RHSA-2010:0011 https://rhn.redhat.com/errata/RHSA-2010-0011.html
Comment 49 Fedora Update System 2010-01-07 19:48:05 EST
nss-3.12.5-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nss-3.12.5-3.fc11
Comment 50 Tomas Hoger 2010-01-15 05:50:29 EST
Transport Layer Security (TLS) Renegotiation Indication Extension:
  http://www.ietf.org/id/draft-ietf-tls-renegotiation-03.txt

has been approved as Proposed Standard by IETF TLS WG:
  http://www.ietf.org/mail-archive/web/tls/current/msg05563.html

It specifies RenegotiationInfo and TLS_RENEGO_PROTECTION_REQUEST Signalling Cipher Suite Value (SCSV) as mechanisms to perform safe renegotiation.

IANA has assigned values for both extension and SCSV:
  http://www.iana.org/assignments/tls-parameters/
  0x00,0xFF  TLS_RENEGO_PROTECTION_REQUEST  [RFC-ietf-tls-renegotiation-03.txt]

  http://www.iana.org/assignments/tls-extensiontype-values/
  65281      renegotiation_info             [RFC-ietf-tls-renegotiation-03.txt]
Comment 52 Fedora Update System 2010-01-25 16:22:00 EST
nss-3.12.5-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-3.12.5-8.fc12
Comment 57 Tomas Hoger 2010-02-01 08:55:35 EST
Public testing servers implementing renegotiation extension:

  https://ssltls.de/
  https://www.mikestoolbox.net/
Comment 59 Fedora Update System 2010-02-04 20:40:00 EST
nss-3.12.5-8.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 60 Tomas Hoger 2010-02-08 05:45:11 EST
IBM JRE 6 SR7 disables renegotiation by default.  Renegotiation behaviour is controlled by the com.ibm.jsse2.renegotiate property.  The default value is NONE (renegotiation not allowed), unsafe renegotiation can be re-enabled by setting the value to ALL.  For additional details, refer to IBM support document:

http://www-01.ibm.com/support/docview.wss?uid=nas258cbfcf0a5645af7862576710041f65e

Updated java-1.6.0-ibm packages were already released for Red Hat Enterprise Linux 4 Extras and Red Hat Enterprise Linux 5 Supplementary:

https://rhn.redhat.com/errata/RHSA-2009-1694.html

Similar change should be included in future versions of 5.0 and 1.4.2 IBM JREs:

http://www.ibm.com/developerworks/java/jdk/alerts/
Comment 61 Tomas Hoger 2010-02-08 05:49:24 EST
(In reply to comment #38)
> Similar mitigation fix as mention for mod_ssl in comment #23 was applied in
> tomcat-native SVN:
>   http://svn.apache.org/viewvc?view=revision&revision=835322
>   http://svn.apache.org/viewvc?view=revision&revision=835335    

The fix is included in tomcat-native 1.1.18 and later:
  http://tomcat.apache.org/security-native.html
Comment 62 Tomas Hoger 2010-02-08 05:54:16 EST
(In reply to comment #45)
> To workaround the vulnerability within tomcat until a fix for JSSE is
> available, the BIO connector configuration offers a
> "allowUnsafeLegacyRenegotiation" attribute from Tomcat 6.0.21 onwards. The
> default value "false" protects against the vulnerability. 
> 
> http://tomcat.apache.org/security-5.html#Not%20a%20vulnerability%20in%20Tomcat
> http://tomcat.apache.org/security-6.html#Not%20a%20vulnerability%20in%20Tomcat

Upstream SVN commits:
http://svn.apache.org/viewvc?view=revision&revision=884998 (tc5.5)
http://svn.apache.org/viewvc?view=revision&revision=881774 (tc6.0)

New "allowUnsafeLegacyRenegotiation" attribute available in Tomcat 6.0.21 and should be available in Tomcat 5.5.29 when it's released.
Comment 65 Tomas Hoger 2010-02-14 05:53:44 EST
TLS Renegotiation Indication Extension specification now available as RFC 5746:
  http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07034.html
  http://www.rfc-editor.org/rfc/rfc5746.txt
Comment 71 Fedora Update System 2010-02-19 17:24:44 EST
proftpd-1.3.2d-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/proftpd-1.3.2d-1.el5
Comment 72 Fedora Update System 2010-02-19 17:26:14 EST
proftpd-1.3.2d-1.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/proftpd-1.3.2d-1.el4
Comment 73 errata-xmlrpc 2010-02-23 15:20:16 EST
This issue has been addressed in tomcat5, tomcat6 and tomcat-native packages in following products:

  JBEWS 1.0.0 for RHEL 4
  JBEWS 1.0.0 for RHEL 5

Via RHSA-2010:0119 https://rhn.redhat.com/errata/RHSA-2010-0119.html
Comment 76 Tomas Hoger 2010-02-26 06:23:50 EST
OpenSSL release 0.9.8m implements RFC 5746:
  http://marc.info/?l=openssl-dev&m=126712103527093&w=2
Comment 77 Andy Grimm 2010-03-01 16:38:33 EST
Is Red Hat's plan for openssl to backport the patch, or to introduce another openssl package against which developers would need to rebuild?
Comment 78 Tomas Hoger 2010-03-02 02:22:31 EST
(In reply to comment #77)
> Is Red Hat's plan for openssl to backport the patch, or to introduce another
> openssl package against which developers would need to rebuild?    

Backport, expected to be released later this month.
Comment 79 Elio Maldonado Batiz 2010-03-02 21:40:36 EST
Created attachment 397463 [details]
Keep SSL_RENEGOTIATE_TRANSITIONAL as the default value

Default renegotiation value has changed to SSL_RENEGOTIATE_REQUIRES_XTN, the code tests for the NSS_SSL_ENABLE_RENEGOTIATION environment variable and honours the user's request. To save the user from having to make changes this patch reverts the default to SSL_RENEGOTIATE_TRANSITIONAL.
Comment 80 errata-xmlrpc 2010-03-03 13:20:17 EST
This issue has been addressed in java-1.5.0-ibm packages in following products:

  Extras for Red Hat Enterprise Linux 5
  Extras for RHEL 4

Via RHSA-2010:0130 https://rhn.redhat.com/errata/RHSA-2010-0130.html
Comment 84 Fedora Update System 2010-03-07 12:49:46 EST
nss-3.12.6-1.2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-3.12.6-1.2.fc12
Comment 85 Fedora Update System 2010-03-07 12:49:57 EST
nss-3.12.6-1.2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nss-3.12.6-1.2.fc11
Comment 86 Fedora Update System 2010-03-07 12:50:07 EST
nss-3.12.6-1.2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-3.12.6-1.2.fc13
Comment 88 Fedora Update System 2010-03-11 08:25:01 EST
nss-3.12.6-1.2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 89 Fedora Update System 2010-03-11 19:04:08 EST
proftpd-1.3.2d-1.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 90 Fedora Update System 2010-03-11 19:04:34 EST
proftpd-1.3.2d-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 91 Fedora Update System 2010-03-11 23:18:24 EST
nss-3.12.6-1.2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 92 cyrushmh 2010-03-12 06:16:57 EST
need saomething --> 无法满足的依赖关系:nspr-devel >= 4.8.4 被包 nss- devel-3.12.6-1.2.fc12.i686 (updates) 所需要 nss-devel-3.12.6-1.2.fc12.i686 来自 updates 存在依赖关系问题 --> 无法满足的依赖关系:pkgconfig(nss-util) >= 3.12.6 被包 nss- devel-3.12.6-1.2.fc12.i686 (updates) 所需要 nss-devel-3.12.6-1.2.fc12.i686 来自 updates 存在依赖关系问题 --> 无法满足的依赖关系:pkgconfig(nspr) >= 4.8.4 被包 nss- devel-3.12.6-1.2.fc12.i686 (updates) 所需要 nss-3.12.6-1.2.fc12.i686 来自 updates 存在依赖关系问题 --> 无法满足的依赖关系:nspr >= 4.8.4 被包 nss-3.12.6-1.2.fc12.i686 (updates) 所需要 nss-3.12.6-1.2.fc12.i686 来自 updates 存在依赖关系问题 --> 无法满足的依赖关系:nss-util = 3.12.6 被包 nss-3.12.6-1.2.fc12.i686 (updates) 所需要 错误:无法满足的依赖关系:pkgconfig(nspr) >= 4.8.4 被包 nss-devel-3.12.6-1.2.fc12.i686 (updates) 所需要 错误:无法满足的依赖关系:pkgconfig (nss-util) >= 3.12.6 被包 nss-devel-3.12.6-1.2.fc12.i686 (updates) 所需要错误:无法满足的依赖关系:nspr-devel >= 4.8.4 被包 nss-devel-3.12.6-1.2.fc12.i686 (updates) 所需要错误:无法满足的依赖关系:nss-util = 3.12.6 被包 nss-3.12.6-1.2.fc12.i686 (updates) 所需要错误:无法满足的依赖关系:nspr >= 4.8.4 被包 nss-3.12.6-1.2.fc12.i686 (updates) 所需要 

I don't want to use 'yum --skip-broken update',because that always when I upgrade next (like 11 > 12) have some big matter.
Comment 93 framercy 2010-03-12 11:47:47 EST
Same Problem here




[root@tobruk ~]# yum --disablepresto update
Geladene Plugins: presto, refresh-packagekit
Einrichten des Aktualisierungsprozess
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Paket nss.i686 0:3.12.6-1.2.fc12 markiert, um aktualisiert zu werden
--> Verarbeite Abhängigkeiten: nss-util = 3.12.6 für Paket: nss-3.12.6-1.2.fc12.i686
--> Verarbeite Abhängigkeiten: nspr >= 4.8.4 für Paket: nss-3.12.6-1.2.fc12.i686
---> Paket nss-sysinit.i686 0:3.12.6-1.2.fc12 markiert, um aktualisiert zu werden
---> Paket nss-tools.i686 0:3.12.6-1.2.fc12 markiert, um aktualisiert zu werden
--> Abhängigkeitsauflösung beendet
nss-3.12.6-1.2.fc12.i686 von updates hat Abhängigkeitsauflöse-Probleme
  --> Fehlende Abhängigkeit: nspr >= 4.8.4 wird benötigt von Paket nss-3.12.6-1.2.fc12.i686 (updates)
nss-3.12.6-1.2.fc12.i686 von updates hat Abhängigkeitsauflöse-Probleme
  --> Fehlende Abhängigkeit: nss-util = 3.12.6 wird benötigt von Paket nss-3.12.6-1.2.fc12.i686 (updates)
Fehler: Fehlende Abhängigkeit: nss-util = 3.12.6 wird benötigt von Paket nss-3.12.6-1.2.fc12.i686 (updates)
Fehler: Fehlende Abhängigkeit: nspr >= 4.8.4 wird benötigt von Paket nss-3.12.6-1.2.fc12.i686 (updates)
 Sie können versuchen --skip-broken zu benutzen, um das Problem zu umgehen.
 Sie können versuchen das folgenden auszuführen: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest
[root@tobruk ~]#
Comment 94 Elio Maldonado Batiz 2010-03-12 12:08:31 EST
See my comments on bug 572876. The packages weren't being pushed to stable in the proper dependency order. For example nss went to stable before nspr and nss-softoken on some fedora versions. I just pushed to stable the remaining dependencies. It make take some more time for all to be in.
Comment 98 errata-xmlrpc 2010-03-17 13:20:00 EDT
This issue has been addressed in java-1.4.2-ibm packages in following products:

  Extras for RHEL 3
  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5

Via RHSA-2010:0155 https://rhn.redhat.com/errata/RHSA-2010-0155.html
Comment 100 Fedora Update System 2010-03-22 22:03:03 EDT
nss-3.12.6-1.2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 101 Fedora Update System 2010-03-23 03:26:52 EDT
openssl-0.9.8m-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/openssl-0.9.8m-1.fc11
Comment 103 Ralf Hauser 2010-03-24 05:43:46 EDT
just FYI: false positives now in the most recent firefox's Error Log https://bugzilla.mozilla.org/show_bug.cgi?id=554594
Comment 105 errata-xmlrpc 2010-03-25 04:52:29 EDT
This issue has been addressed in openssl packages in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0162 https://rhn.redhat.com/errata/RHSA-2010-0162.html
Comment 106 errata-xmlrpc 2010-03-25 05:15:53 EDT
This issue has been addressed in openssl packages in following products:

  Red Hat Enterprise Linux 3
  Red Hat Enterprise Linux 4

Via RHSA-2010:0163 https://rhn.redhat.com/errata/RHSA-2010-0163.html
Comment 107 errata-xmlrpc 2010-03-25 05:30:55 EDT
This issue has been addressed in openssl097a packages in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0164 https://rhn.redhat.com/errata/RHSA-2010-0164.html
Comment 108 errata-xmlrpc 2010-03-25 06:05:34 EDT
This issue has been addressed in nss packages in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 4

Via RHSA-2010:0165 https://rhn.redhat.com/errata/RHSA-2010-0165.html
Comment 109 errata-xmlrpc 2010-03-25 06:19:40 EDT
This issue has been addressed in gnutls packages in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0166 https://rhn.redhat.com/errata/RHSA-2010-0166.html
Comment 110 errata-xmlrpc 2010-03-25 06:38:51 EDT
This issue has been addressed in gnutls packages in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0167 https://rhn.redhat.com/errata/RHSA-2010-0167.html
Comment 111 Fedora Update System 2010-03-25 08:52:46 EDT
openssl-0.9.8n-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/openssl-0.9.8n-1.fc11
Comment 113 Fedora Update System 2010-03-30 08:26:49 EDT
openssl-1.0.0-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openssl-1.0.0-1.fc12
Comment 114 Tomas Hoger 2010-03-31 05:33:06 EDT
(In reply to comment #60)
> IBM JRE 6 SR7 disables renegotiation by default.  Renegotiation behaviour is
> controlled by the com.ibm.jsse2.renegotiate property.

Sun JRE 6 Update 19 disables renegotiation by default too.  The property that can be used to control renegotiation behaviour is:

  sun.security.ssl.allowUnsafeRenegotiation

Values: false (default, renegotiation not allowed), true (unsafe renegotiation allowed)

For more details, refer to the Oracle "Transport Layer Security (TLS) Renegotiation Issue Readme":

  http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html

Same fix and property will be used in OpenJDK JRE too.
Comment 116 errata-xmlrpc 2010-03-31 20:14:43 EDT
This issue has been addressed in java-1.6.0-openjdk packages in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0339 https://rhn.redhat.com/errata/RHSA-2010-0339.html
Comment 117 errata-xmlrpc 2010-03-31 20:21:37 EDT
This issue has been addressed in java-1.6.0-sun packages in following products:

  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5

Via RHSA-2010:0337 https://rhn.redhat.com/errata/RHSA-2010-0337.html
Comment 118 errata-xmlrpc 2010-03-31 22:56:48 EDT
This issue has been addressed in following products:

  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5
  Supplementary for RHEL 5.2.z
  Supplementary for RHEL 5.3.z

Via RHSA-2010:0338 https://rhn.redhat.com/errata/RHSA-2010-0338.html
Comment 120 Fedora Update System 2010-04-06 12:34:24 EDT
java-1.6.0-openjdk-1.6.0.0-34.b17.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-34.b17.fc11
Comment 121 Fedora Update System 2010-04-06 12:36:53 EDT
java-1.6.0-openjdk-1.6.0.0-37.b17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-37.b17.fc12
Comment 122 Fedora Update System 2010-04-07 03:11:10 EDT
java-1.6.0-openjdk-1.6.0.0-36.b17.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-36.b17.fc13
Comment 123 Fedora Update System 2010-04-08 21:27:49 EDT
java-1.6.0-openjdk-1.6.0.0-37.b17.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 124 Fedora Update System 2010-04-08 21:31:31 EDT
java-1.6.0-openjdk-1.6.0.0-34.b17.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 125 Fedora Update System 2010-04-09 02:56:13 EDT
java-1.6.0-openjdk-1.6.0.0-37.b17.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-37.b17.fc13
Comment 126 Fedora Update System 2010-04-09 17:04:30 EDT
java-1.6.0-openjdk-1.6.0.0-37.b17.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 127 Fedora Update System 2010-04-16 19:49:12 EDT
openssl-0.9.8n-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 128 Tomas Hoger 2010-04-19 02:37:57 EDT
Support for RFC 5746 was added to NSS in version 3.12.6.  Release notes for that version are now available on Mozilla site:
  https://developer.mozilla.org/NSS_3.12.6_release_notes
Comment 134 errata-xmlrpc 2010-05-12 12:21:49 EDT
This issue has been addressed in java-1.4.2-ibm packages in following products:

  RHEL 4 for SAP
  RHEL 5 for SAP

Via RHSA-2010:0408 https://rhn.redhat.com/errata/RHSA-2010-0408.html
Comment 136 Fedora Update System 2010-05-18 12:53:35 EDT
openssl-1.0.0-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openssl-1.0.0-4.fc12
Comment 137 Fedora Update System 2010-05-25 14:41:16 EDT
openssl-1.0.0-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 138 errata-xmlrpc 2010-05-25 16:42:00 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Virtualization for RHEL-5

Via RHSA-2010:0440 https://rhn.redhat.com/errata/RHSA-2010-0440.html
Comment 140 Fedora Update System 2010-06-03 08:33:39 EDT
gnutls-2.8.6-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/gnutls-2.8.6-2.fc13
Comment 141 Fedora Update System 2010-06-03 08:34:02 EDT
gnutls-2.8.6-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gnutls-2.8.6-2.fc12
Comment 142 Fedora Update System 2010-06-22 13:20:31 EDT
gnutls-2.8.6-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 143 Fedora Update System 2010-06-25 14:14:39 EDT
gnutls-2.8.6-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 146 errata-xmlrpc 2010-10-13 12:24:15 EDT
This issue has been addressed in java-1.6.0-openjdk packages in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0768 https://rhn.redhat.com/errata/RHSA-2010-0768.html

Note: This update adds RFC 5746 support.
Comment 147 errata-xmlrpc 2010-10-14 09:37:02 EDT
This issue has been addressed in java-1.6.0-sun packages in following products:

  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5

Via RHSA-2010:0770 https://rhn.redhat.com/errata/RHSA-2010-0770.html

Note: This update adds RFC 5746 support.
Comment 148 Tomas Hoger 2010-10-14 11:52:23 EDT
RFC 5746 support is now available in Sun/Oracle and OpenJDK Java packages.  Properties sun.security.ssl.allowUnsafeRenegotiation (default: false) and sun.security.ssl.allowLegacyHelloMessages (default: true) can be used to control safe renegotiation behaviour.  For additional details, refer to:

http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html
Comment 152 errata-xmlrpc 2010-10-20 13:15:30 EDT
This issue has been addressed in java-1.4.2-ibm packages in following products:

  Extras for RHEL 3
  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5

Via RHSA-2010:0786 https://rhn.redhat.com/errata/RHSA-2010-0786.html
Comment 154 errata-xmlrpc 2010-10-27 19:07:51 EDT
This issue has been addressed in java-1.5.0-ibm packages in following products:

  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5

Via RHSA-2010:0807 https://rhn.redhat.com/errata/RHSA-2010-0807.html
Comment 155 Tomas Hoger 2010-10-29 03:25:43 EDT
The above java-*-ibm updates add support for RFC 5746 to IBM JRE.  Renegotiation behaviour can be controlled using the com.ibm.jsse2.renegotiate (default: NONE), com.ibm.jsse2.extended.renegotiation.indicator (default: OPTIONAL) and com.ibm.jsse2.renegotiation.peer.cert.check (default: OFF) system properties.  For additional details, refer to:
http://www.ibm.com/developerworks/java/jdk/security/50/secguides/jsse2Docs/JSSE2_RFC5746.html
http://www-01.ibm.com/support/docview.wss?uid=swg1IZ75870
Comment 156 errata-xmlrpc 2010-11-10 13:49:58 EST
This issue has been addressed in java-1.6.0-openjdk packages in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2010:0865 https://rhn.redhat.com/errata/RHSA-2010-0865.html
Comment 158 errata-xmlrpc 2010-12-15 17:44:18 EST
This issue has been addressed in java-1.4.2-ibm-sap packages in following products:

  RHEL 4 for SAP
  RHEL 5 for SAP
  RHEL 6 for SAP

Via RHSA-2010:0986 https://rhn.redhat.com/errata/RHSA-2010-0986.html
Comment 159 errata-xmlrpc 2010-12-15 18:46:00 EST
This issue has been addressed in java-1.6.0-ibm packages in following products:

  Extras for RHEL 4
  Extras for Red Hat Enterprise Linux 5
  Extras for Red Hat Enterprise Linux 6

Via RHSA-2010:0987 https://rhn.redhat.com/errata/RHSA-2010-0987.html
Comment 160 errata-xmlrpc 2011-06-16 15:22:48 EDT
This issue has been addressed in following products:

  Red Hat Network Satellite Server v 5.4

Via RHSA-2011:0880 https://rhn.redhat.com/errata/RHSA-2011-0880.html
Comment 161 Jan Lieskovsky 2011-09-26 07:29:09 EDT
(In reply to comment #45)
> CVE-2009-3555 affects Tomcat if connectors are configured that use a vulnerable
> TLS implementation.  
> 
> The APR connector relies on OpenSSL, and is vulnerable if the version of
> OpenSSL is vulnerable.
> 
> NIO (non-blocking IO) and BIO (blocking IO) connectors use the JSSE
> implementation of the underlying JRE. 
> 
> The NIO connector is not affected, as it does not support renegotiation.
> 
> To workaround the vulnerability within tomcat until a fix for JSSE is
> available, the BIO connector configuration offers a
> "allowUnsafeLegacyRenegotiation" attribute from Tomcat 6.0.21 onwards. The
> default value "false" protects against the vulnerability. 
> 
> http://tomcat.apache.org/security-5.html#Not%20a%20vulnerability%20in%20Tomcat
> http://tomcat.apache.org/security-6.html#Not%20a%20vulnerability%20in%20Tomcat

For Tomcat v5.* support for the new TLS renegotiation protocol (RFC 5746) that does not have this security issue:

  - For connectors using JSSE implementation provided by JVM: Added
    in Tomcat 5.5.33. Requires JRE that supports RFC 5746. For Oracle
    JRE that is known to be 6u22 or later. 
  - For connectors using APR and OpenSSL: TBD. See APR/native connector
    security page:
    http://tomcat.apache.org/security-native.html

For Tomcat v6.* support for the new TLS renegotiation protocol (RFC 5746) that does not have this security issue:

  - For connectors using JSSE implementation provided by JVM: Added
    in Tomcat 6.0.32. Requires JRE that supports RFC 5746. For Oracle
    JRE that is known to be 6u22 or later.
  - For connectors using APR and OpenSSL: TBD. See APR/native connector
    security page:
    http://tomcat.apache.org/security-native.html
Comment 162 Vincent Danen 2012-12-21 11:46:15 EST
For Tomcat v7.* support for the new TLS renegotiation protocol (RFC 5746) that does not have this security issue:

- For connectors using JSSE implementation provided by JVM: Added in Tomcat 7.0.8. Requires JRE that supports RFC 5746. For Oracle JRE that is known to be 6u22 or later.
- For connectors using APR and OpenSSL: TBD. See APR/native connector security page: http://tomcat.apache.org/security-native.html