Bug 533125 (CVE-2009-3555)

Independent discovery by Martin Rex:
  http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

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.

Proposed patches for GnuTLS from PhoneFactor:
  http://lists.gnu.org/archive/html/gnutls-devel/2009-11/msg00014.html

(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.

TLS Renegotiation Indication Extension proposed RFC draft:

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

(source: http://www.ietf.org/mail-archive/web/tls/current/msg03963.html)

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

Wrong mozilla bug. Here's the correct one:
https://bugzilla.mozilla.org/show_bug.cgi?id=526689

bob

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

Created attachment 367773 [details]
NSS patch to turn off renegotiation

This is still a preliminary patch. There is still more testing needed on it.

Once the official patch is ready, it should land in the NSS public source tree.

bob

(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

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.

Red Hat Knowledgebase article:
  http://kbase.redhat.com/faq/docs/DOC-20491

(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.

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

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

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.

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

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).

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)

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

(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

(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

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

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

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.

US-CERT Vulnerability Note VU#120541 covering this flaw:
  http://www.kb.cert.org/vuls/id/120541

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.

PhoneFactor status tracking page:
http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches

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.

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 patch for nginx is here: http://sysoev.ru/nginx/patch.cve-2009-3555.txt

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?

(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.

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

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.

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.

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

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

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]

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

Public testing servers implementing renegotiation extension:

  https://ssltls.de/
  https://www.mikestoolbox.net/

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.

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/

(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

(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.

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

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

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

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

OpenSSL release 0.9.8m implements RFC 5746:
  http://marc.info/?l=openssl-dev&m=126712103527093&w=2

Is Red Hat's plan for openssl to backport the patch, or to introduce another openssl package against which developers would need to rebuild?

(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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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 ~]#

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.

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

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.

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

just FYI: false positives now in the most recent firefox's Error Log https://bugzilla.mozilla.org/show_bug.cgi?id=554594

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

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

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

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

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

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

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

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

(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.

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

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

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

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

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

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

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.

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.

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

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.

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.

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

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

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

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.

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

(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

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