Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Emmanuel Dreyfus (manunetbsd.org)
Date: Sun Jul 04 2010 - 00:30:30 CDT
I forward here this message I posted to netbsd-users and that got no anwser.
As I understand, the only fix to the TLS renegociation attack for now is to
disable renegociation. Firefox does it, and as I understand, NetBSD 5.0.2's
OpenSSL does that too. Am I right?
When Apache says""Re-negotiation handshake failed: Not accepted by client!?",
it suggests that Firefox refused to do the renegociation, but also that Apache
was willing to perform it. Since it is linked against NetBSD-5.0.2's libssl,
that should not happen. Or perhaps Apache renegociation refusal would occur
later in the transaction, after Firefox would have accepted it? If someone can
shed light on this, it would be nice.
Another problem is how to workaround the workaround. As I underdstand, client
certificate authentication requires renegociation if it is not enabled
server-wide: in that situation, the SSL handshake occurs, the the client
requests a ressource requiring client certificate, and the server starts a
renegociation so that the client can send its certificate.
Hence, an httpd.conf with an altenrate <VirtualHost> that has "SSLVerifyClient
require" for the whole virtualhost (and not for a particular <Directory> or
<Location>) should work. I gave it a try without any success. Are there other
option that could cause renegociation?
------- Begin Forwarded Message -------
Subject: Apache and client certificate on NetBSD 5.0.2
From: Emmanuel Dreyfus <manunetbsd.org>
Date: Sun, 27 Jun 2010 12:00:36 +0200
I have an Apache that performed client certificate authentication some
time ago. Here is the relevant part of httpd.conf:
That used to work, but now the connexion aborts, and Apache logs say:
"Re-negotiation handshake failed: Not accepted by client!?"
It seems it happens for any client: I tried latest Firefox and Safari on
the a MacOS X machine, and wget on the same machine Apache is running
I suspect this is the workaround for the TLS renegociation bug that
turned bad. A search on the web leads to this thread:
And in the thread we get this fix:
I tried applying it to NetBSD-5.0.2 in-tree openssl. It needs a minor
tweaks, but that does not solve the problem: the same problem happens
with the patched libssl.
Any idea, anyone?
-------- End Forwarded Message --------