Your message dated Sun, 22 Mar 2026 09:38:51 +0100
with message-id <[email protected]>
and subject line Re: Bug#672456: CVE-2011-1473: SSL/TLS DoS via repeated SSL
session renegotiations
has caused the Debian Bug report #672456,
regarding CVE-2011-1473: SSL/TLS DoS via repeated SSL session renegotiations
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
672456: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672456
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: openssl
Version: 0.9.8o-4squeeze12
Severity: important
Tags: security
https://bugzilla.redhat.com/show_bug.cgi?id=707065
"""
It was reported [1] that a flaw exists in how openSSL handles SSL
renegotiation. Because of the processing power required to handle an SSL/TLS
handshake, with renegotiation enabled, a user can send multiple handshakes per
second due to the renegotiation request being permitted. This could allow a
malicious user to send multiple renegotiation requests and exhaust server
resources.
Note that this is not the only way to cause a denial of service on an
SSL-enabled service; there are many other ways to accomplish the same thing,
this just makes it easier.
What makes this bug even more confusing is that this report is recent, with a
2011 CVE, however the recommended fix in the report is to upgrade to OpenSSL
0.9.8l, which is what disabled renegotiation, however it was subsequently
re-enabled when OpenSSL added support for RFC5746 in OpenSSL 0.9.8m (which the
reporter seems to imply isn't sufficient). I'm not sure where the CVE
assignment came from; on MITRE's site is is reserved yet and I have not seen
this discussed anywhere else but in a Nessus scan report [2].
As an aside, and to reference something we may need to look at, there seems to
be some concern with Apache and how it works with SSL renegotiation disabled
[3], so we will need to look into cases where disabling SSL renegotiation may
impact expected behaviour of currently released products.
[1] http://orchilles.com/2011/03/ssl-renegotiation-dos.html
[2] https://discussions.nessus.org/message/10629
[3]
http://old.nabble.com/TLS-renegotiation-disabling-%3A-mod_ssl-and-OpenSSL--0.9.8l-td26285568.html
"""
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openssl depends on:
ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib
ii libssl0.9.8 0.9.8o-4squeeze12 SSL shared libraries
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
openssl recommends no packages.
Versions of packages openssl suggests:
ii ca-certificates 20090814+nmu3squeeze1 Common CA certificates
-- no debconf information
--- End Message ---
--- Begin Message ---
On 2012-05-11 11:18:11 [+0300], Henri Salo wrote:
> It was reported [1] that a flaw exists in how openSSL handles SSL
> renegotiation. Because of the processing power required to handle an SSL/TLS
> handshake, with renegotiation enabled, a user can send multiple handshakes per
> second due to the renegotiation request being permitted. This could allow a
> malicious user to send multiple renegotiation requests and exhaust server
> resources.
This is protocol issue and there is nothing that can be done without
breaking the expectations on the other side.
Things that changed in the meantime and make me sleep well while closing
this:
- moving to an EC key makes this less of an issue because renegotiation
with an EC key is cheaper than with RSA/ DH with equivalent security.
EC keys is something that is widely supported now and even a few years
back so I don't expect anyone saying "can't do EC".
- There is RFC 5746 (Secure Renegotiation) in place. This should address
the repeated renegotiation issue.
- TLS v1.3 does not support renegotiation.
As of today I would say disable renegotiation and use TLS v1.3+ if this
is a concern.
Sebastian
--- End Message ---
