Thanks for the background information. Once I understood the the
reasons behind what you're asking, I looked at the temporary-workaround
patches to both OpenSSL and Apache HTTP Server from the time
CVE-2009-3555 was published, since my memory said that the workarounds
were to disable client renegotiation. I think it is actually better to
disable client-initiated renegotiation in OpenSSL rather than in Apache
HTTP Server, since an OpenSSL based solution will prevent TLS based DoS
attacks in other protocols, too (LDAPS, IMAP, SMTP, FTPS, ...)
However, since this is the Apache HTTP Server mailing list, here is what
I found relating to httpd:
It looks to me like httpd rejects client-initiated TLS renegotiation
out-of-the-box and hence you should not need to do anything in order to
achieve your goal.
I'm running httpd 2.3.12-dev (2011-03-10 snapshot from SVN) with OpenSSL
1.0.0d-fips under Fedora 14; but I've also checked the httpd 2.2.17
source code (see below for details).
I followed the instructions at
http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html
for testing to see if client-initiated TLS renegotiations are allowed.
My test indicates that client initiated renegotiations are rejected:
$ openssl s_client -connect f14dev1.catseye.org:443
[...lots of output omitted...]
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
[...more output omitted...]
GET / HTTP/1.0
R
RENEGOTIATING
140716401080128:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:590:
$
I also repeated the above test with the -ssl3 option to "openssl
s_client" which gave the same results.
Can you do this test on your end and let me know if you get different
results? If you discover that your installation of Apache HTTP Server
accepts client-initiated TLS renegotiations, please include the
I've also investigated the source code for Apache HTTP Server 2.2.17 and
compared it to the temporary workaround patch for CVE-2009-3555.
Here is the announcement of the temporary workaround:
http://marc.info/?l=apache-httpd-announce&m=125755783724966&w=2
Here is the patch for the temporary workaround:
http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
I've gone through the source code for Apache HTTP Server 2.2.17 and it
looks to me like everything from the temporary workaround is still in
place. In particular, the last part of the patch adds a
ssl_callback_Info() function (see the file
modules/ssl/ssl_engine_kernel.c lines 1926 - 1970) which disallows any
client-initiated renegotiations after the initial handshake has been
completed.
So hopefully you won't need to do anything on your end, at least not as
far as TLS renegotiation DoS attacks against Apache HTTP Server are
concerned.
--
Mark Montague
m...@catseye.org
On April 9, 2011 20:27 , Chris Hill <chris.hill...@gmail.com> wrote:
Nothing wrong with re-negotiation if used for what it was intended.
Now, since a server cannot limit how many of these a client can
request, this leaves the doors open to abuse (DoS --not to be confused
with DDoS).
To me, disabling it would be as good as limiting how many times a
client can request renegotiation.
There are actual attacks taking advantage of it, and security vendors
(IDS/IPS) are already working on ways to detect these. However,
vendors are falling behind when it comes to providing a good solution
that can allow system administrators to limit user's trying to take
advantage of this.
If you are serious about this and want to provide a solution to
disable re-negotiation altogether, I would share more info on how this
is being exploited.
Chris.
On Sat, Apr 9, 2011 at 7:37 PM, Mark Montague <m...@catseye.org
<mailto:m...@catseye.org>> wrote:
On April 9, 2011 18:00 , Chris Hill <chris.hill...@gmail.com
<mailto:chris.hill...@gmail.com>> wrote:
My company relies on Apache for a number of customer facing
sites. What's a reliable way to disable client initiated
renegotiation (both secure and insecure renegotiation)?. I
know one specific openssl library (l) disables this, but then
later ones enable "secure" renegotiation, which we need to
disable.
Ideally, I'd like a solution through an configuration
parameter so that future versions/upgrades do not re-enable
renegotiation.
I don't have an answer for you, but, out of curiosity, why do you
need to disable SSL 3.0 / TLS renegotiation? If a client
initiates a renegotiation, is this bad in some way? Obviously,
you trusted the client during the initial negotiation/handshake.
--
Mark Montague
m...@catseye.org <mailto:m...@catseye.org>
--
Mark Montague
m...@catseye.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
