On Sun, 24 Jan 2010 15:12:40 +0100, Dr. Stephen Henson st...@openssl.org
wrote:
I've traced the cause this was *fun*. The full story is in:
http://cvs.openssl.org/chngview?cn=19145
This is a case of a bug in OpenSSL (PR#1949) being fixed but a related bug in
Apache still existing in older
Dr. Stephen Henson wrote:
On Sat, Jan 23, 2010, Dr. Stephen Henson wrote:
On Fri, Jan 22, 2010, Michael Stone wrote:
This certainly looks like a 12-byte verify_data field encoded as a
variable-length vector (i.e. prefixed with a 1-byte length).
6. We receive a fatal
On Mon, Jan 25, 2010, Frederick Shotton wrote:
Hi Steve,
I tried the new fix and it did not work for me. The Apache only fix did
make renegotiation work however. The new fix hangs with the following
output on s_client:
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is
Subject: Re: Re-negotiation handshake failed: Not accepted by client
withOpenSSL 0.98m-beta1
On Mon, Jan 25, 2010, Frederick Shotton wrote:
Hi Steve,
I tried the new fix and it did not work for me. The Apache only fix did
make renegotiation work however. The new fix hangs with the following
On Mon, Jan 25, 2010, Shotton, Fred wrote:
Hi Steve,
Adding a third case in s3_srvr.c did work, yeah! Applying the Apache fix did
not work.
Let me know if you need anything else.
I can't reproduce your issue but it does depend critically on the amount of
data transferred to reproduce
On Sat, Jan 23, 2010, Dr. Stephen Henson wrote:
On Fri, Jan 22, 2010, Michael Stone wrote:
This certainly looks like a 12-byte verify_data field encoded as a
variable-length vector (i.e. prefixed with a 1-byte length).
6. We receive a fatal unexpected_message alert:
: Re-negotiation handshake failed: Not accepted by client with
OpenSSL 0.98m-beta1
On Sat, Jan 23, 2010, Dr. Stephen Henson wrote:
Just a quick note. I can reproduce this now and I'm investigating it further.
I've traced the cause this was *fun*. The full story is in:
http
On Fri, Jan 22, 2010, Michael Stone wrote:
This certainly looks like a 12-byte verify_data field encoded as a
variable-length vector (i.e. prefixed with a 1-byte length).
6. We receive a fatal unexpected_message alert:
TLS 1.0 Alert [length 0002], fatal
Dear openssl-users@ and, in particular, Dr. Henson,
First, apologies that I didn't realize I was writing to you in my
previous response to Fred. I'll check my To: lines more carefully in the
future.
Second, thanks for your earlier assistance in diagnosing this
issue. Your suggestions have led
On Fri, Jan 22, 2010, Michael Stone wrote:
Dear openssl-users@ and, in particular, Dr. Henson,
First, apologies that I didn't realize I was writing to you in my
previous response to Fred. I'll check my To: lines more carefully in the
future.
Second, thanks for your earlier assistance in
On Wed, Jan 20, 2010, Shotton, Fred wrote:
I'm running apache 2.2.14 with mod_ssl using OpenSSL 0.98m-beta1. When
renegotiating a client session, I get an error from apache: Re-negotiation
handshake failed: Not accepted by client and a fatal unexpected_message
alert in OpenSSL s_client. Below
On Wed, Jan 20, 2010, Shotton, Fred wrote:
I'm running apache 2.2.14 with mod_ssl using OpenSSL 0.98m-beta1. When
renegotiating a client session, I get an error from apache: Re-negotiation
handshake failed: Not accepted by client and a fatal unexpected_message
alert in OpenSSL s_client
Dr. Stephen Henson wrote:
On Wed, Jan 20, 2010, Shotton, Fred wrote:
I'm running apache 2.2.14 with mod_ssl using OpenSSL 0.98m-beta1.
When renegotiating a client session, I get an error from apache:
Re-negotiation handshake failed: Not accepted by client and a fatal
unexpected_message
On Wed, 20 Jan 2010 20:33:34 -0500, Shotton, Fred fshot...@akamai.com wrote:
I'm running apache 2.2.14 with mod_ssl using OpenSSL 0.98m-beta1. When
renegotiating a client session, I get an error from apache:
Re-negotiation handshake failed: Not accepted by client and a fatal
unexpected_message
Hi,
thank you for your detailed explanations.
The main thing I still not understood is whether TLS by design
enforces the `bad behavior', meaning TLS cannot be used securely
at all by anyone,
- or -
if TLS just does not enforce to use is securely, meaning that TLS
relies on application code
Hi,
thank you too for the detailed explanation. But the impact on
the client certificates (and its correct validation etc) is not
clear to me (so I ask inline in the second half of this mail).
* Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800:
The most succinct answer is this: the
Responses inline. :)
On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER steffen.dett...@ingenico.com
wrote:
Hi,
thank you too for the detailed explanation. But the impact on
the client certificates (and its correct validation etc) is not
clear to me (so I ask inline in the second half of this
Responses inline, again. :)
On Tue, Jan 12, 2010 at 2:53 AM, Steffen DETTMER
steffen.dett...@ingenico.com wrote:
The main thing I still not understood is whether TLS by design
enforces the `bad behavior', meaning TLS cannot be used securely
at all by anyone,
- or -
if TLS just does not
Hi all!
I miss something around the Re-negotiation flaw and fail to
understand why it is a flaw in TLS. I hope I miss just a small
piece. Could anyone please enlight me?
* Kyle Hamilton wrote on Thu, Jan 07, 2010 at 16:22 -0800:
It is also, though, undeniably a flaw in the TLS specification
Steffan Dettmer write:
Could it be considered that a miss-assumption about SSL/TLS
capabilities caused this situation?
Only with hindsight.
I think since TLS should be considered a layer, its payload
should not make any assumptions to it (or vice versa). But in the
moment some
The most succinct answer is this: the server and client
cryptographically only verify the session that they renegotiate within
at the time of initial negotiation, and never verify that they're the
same two parties that the session was between at the time of
renegotiation.
This allows for a MITM
On 08.01.2010 07:11, Kyle Hamilton wrote:
On Thu, Jan 7, 2010 at 5:20 PM, Lou Piccianoloupicci...@comcast.net wrote:
Kyle,
Meanwhile, as we now gird our loins for the impending reversion of many big
apps on our servers (only to re-implement updates when openSSL 0.0.8m
becomes available!), is
openSSL v0.9.8l. Suddenly, mod_ssl is reporting:
Re-negotiation handshake failed: Not accepted by client!?
Other than a refresh of CRL, this configuration has been running AOK
through openSSL 0.9.8k...
Before we embark on the complete rebuild of the server: Would a
version of mod_ssl compiled
loupicci...@comcast.net wrote:
Anyone have any ideas on this?
Have recently updated an otherwise working environment to include openSSL
v0.9.8l. Suddenly, mod_ssl is reporting:
Re-negotiation handshake failed: Not accepted by client!?
Other than a refresh of CRL, this configuration has been
Eastern
Subject: Re: Re-negotiation handshake failed: Not accepted by client!?
Renegotiation is disabled in 0.9.8l due to the prefix-injection attack
flaw that the IETF/TLS group just approved a draft standard to fix.
I expect 0.9.8m to have the new renegotiation semantics enabled.
Until
On Thu, Jan 7, 2010 at 5:20 PM, Lou Picciano loupicci...@comcast.net wrote:
Kyle,
Meanwhile, as we now gird our loins for the impending reversion of many big
apps on our servers (only to re-implement updates when openSSL 0.0.8m
becomes available!), is there any tweaking of a simple
26 matches
Mail list logo
