CVE-2009-3555 (retired)

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in
Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache
HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and
earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier,
multiple Cisco products, and other products, does not properly associate
renegotiation handshakes with an existing connection, which allows
man-in-the-middle attackers to insert data into HTTPS sessions, and
possibly other types of sessions protected by TLS or SSL, by sending an
unauthenticated request that is processed retroactively by a server in a
post-renegotiation context, related to a "plaintext injection" attack, aka
the "Project Mogul" issue.
 jdstrand> Fixing this issue requires coordination between the IETF, SSL
  libraries (eg OpenSSL and GnuTLS) and TLS consumers (notably HTTPS servers,
  but most (or all) servers using TLS which support TLS renegotiation).
  Protocol-breaking changes are among the possibilities being
  The following is based on
  and You are encouraged to
  read this document as well as the email thread on ietf-tls for complete
  information and most up-to-date status (see References).
  There are essentially 3 types of renegotiation scenarios known at this time
  to be vulnerable, and they all require a man-in-the-middle (MITM) attack:
  1. Client certificate authentication: servers configured to require client
  certificate authentication on a per-directory basis. Apache is known
  to be vulnerable when using this configuration. There is no generally
  usable mitigation strategy known at this time.
  2. Differing server cryptographic requirements: servers configured to
  support different cipher suites within the same site. One mitigation
  strategy is to require all content on a site to use a single cipher
  suite. Disallowing specification of TLS parameters in .htaccess files
  (generally modifiable by end users) may also be a good idea.
  3. Client-initiated renegotiation: servers configured for TLS. Apache is
  known to be vulnerable when using using TLS and the client initiates a
  renegotiation. There is no generally usable mitigation strategy known at
  this time.
  The flaw should not allow the attacker to see the contents of the connection,
  and a client cannot be redirected to another site. For the HTTPS scenarios
  listed above, the attacker is able to perform arbitrary requests with the
  credentials of the victim. Arbitrary POST requests may also be possible.
  Analysis on the effects of this flaw for other protocols is ongoing.
  Until a general fix can be found for Ubuntu, users may be interested in
  reading, which has a patch to OpenSSL to disable
  all renegotiation.
 jdstrand> Update for apache2 disabled client initiated renegotiations. This
  won't fix per-Directory/Location configurations.
 mdeslaur> openssl 0.9.8l disabled renegotiations completely, with a compile
  time option to turn it back on. This may break connections to servers that
  haven't been patched. openssl 0.9.8m adds an option that applications can
  use to turn it back on:
 mdeslaur> Turning renegotiation off completely may break postgresql, openvpn
  alpine, psi, fetchmail, etc.
 jdstrand> NSS 3.12.6 has support for the new renegotiation extension for TLS
  to implement rfc5746. NSS clients advertise their support for this
  extension and if the server also supports it, will be protected from this
  vulnerability. To maintain compatibility, NSS in Ubuntu will for the
  foreseeable future use the so-called 'transitional' mode which will fall back
  to the unprotected renegotiation method if the server doesn't support the
  new extension.
 jdstrand> NSS was fixed in Ubuntu 9.10 because the new Firefox required it.
  Because Firefox needs changes to take advantage of the new NSS, once Ubuntu
  8.04 LTS - 9.04 are updated to use an embedded NSS (and therefore won't use
  the system NSS), we can update the system NSS for these releases.
 jdstrand> When upgrading the system NSS on Ubuntu 8.04 LTS - 9.04, be careful
  about and
  (regressions seen with the 9.10 update).
 jdstrand> postgresql 8.1.20, 8.3.10 and 8.4.3 now have ssl_renegotiation_limit
  to control session key renegotiation
 jdstrand> preliminary GNUtls patches at (in 2.9.10 development release):
 mdeslaur> jetty 6.1.22 has a CVE-2009-3555 fix: "Prevent SSL renegotiate
  for SSL vulnerability"
 jdstrand> RedHat RHSA-2010:0396-01 adds the "SSLInsecureRenegotiation"
  configuration directive to apache
 mdeslaur> gnutls doesn't have an API for renegotiations, so ignoring.
Source: nss (LP Ubuntu Debian)
Upstream:released (3.12.6)
Upstream:released (6b18~pre4-1)
Upstream:released (6b22)
Upstream:released (6.22)
More Information

Updated: 2019-03-26 11:49:13 UTC (commit ccdecfcf0fead22bd291e5f4ea745a46872dcb15)