On Tue, Jan 26, 2010, Shotton, Fred wrote:
> Hi Steve,
>
> I have verified the new change solves the problem.
>
>
Excellent, thanks for running the tests.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
Hi Steve,
I have verified the new change solves the problem.
Thank you,
fred
-Original Message-
From: Dr. Stephen Henson [mailto:st...@openssl.org]
Sent: Tuesday, January 26, 2010 11:56 AM
To: openssl-users@openssl.org
Subject: Re: Re-negotiation handshake failed: Not accepted
On Tue, Jan 26, 2010, Shotton, Fred wrote:
>
> I double checked that swapping BIO_CTRL_PENDING and BIO_CTRL_WPENDING in
> modules/ssl/ssl_engine_io.c does NOT fix this. It results in a fatal alert,
> without it the s_client hangs. My test is a little unusual in that I
> copy/paste an HTTP GET req
nssl-users@openssl.org
Subject: Re: Re-negotiation handshake failed: Not accepted by clientwithOpenSSL
0.98m-beta1
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 y
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 repr
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 ha
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
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.
On Sun, 24 Jan 2010 15:12:40 +0100, "Dr. Stephen Henson"
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 versions.
egotiation 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:
ht
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
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 une
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 assista
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 me
On Wed, 20 Jan 2010 20:33:34 -0500, "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 fat
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
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
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 "unexpecte
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 you wil
Responses inline, again. :)
On Tue, Jan 12, 2010 at 2:53 AM, Steffen DETTMER
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 enforce to use is securely, m
Responses inline. :)
On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER
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 mail).
* Kyle Hamilton 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 mail).
* Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800:
> The most succinct answer is this: the serve
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 imple
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 to
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 appli
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
> t
On 08.01.2010 07:11, Kyle Hamilton wrote:
On Thu, Jan 7, 2010 at 5:20 PM, Lou Picciano 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
On Thu, Jan 7, 2010 at 5:20 PM, Lou Picciano 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 SSL-enabled Apache
> /Directo
:00 US/Canada 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.
()/write() pair) without the application necessarily being aware
of the change.
-Kyle H
On Thu, Jan 7, 2010 at 12:50 PM, Lou Picciano wrote:
> Anyone have any ideas on this?
>
> Have recently updated an otherwise working environment to include openSSL
> v0.9.8l. Suddenly, mod_ssl i
o 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 running AOK
> through openSSL 0.9.8k...
> Before we embark on the complete rebuild of the server:
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 running AOK through
openSSL
ion doesn't help..
Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Andrejs Igumenovs
Sent: Monday, 03 August, 2009 07:08
This succeed with "ssleay32.dll v0.9.8.4" and it fails with
"ssleay32.dll v0.9.8.11".
2009-08-03 13:40:25,911 DEBUG
[org.apache
2009 07:08
This succeed with "ssleay32.dll v0.9.8.4" and it fails with
"ssleay32.dll v0.9.8.11".
2009-08-03 13:40:25,911 DEBUG
[org.apache.tomcat.util.net.PoolTcpEndpoint] Handshake failed
javax.net.ssl.SSLException: Unexpected end of handshake data
What could be the
t;.
2009-08-03 13:40:25,911 DEBUG
[org.apache.tomcat.util.net.PoolTcpEndpoint] Handshake failed
javax.net.ssl.SSLException: Unexpected end of handshake data
What could be the reason and where should I dig into ?
0.9.8j (and thus k) enabled extensions by default, one of which
changes the ClientHe
> From: owner-openssl-us...@openssl.org On Behalf Of Andrejs Igumenovs
> Sent: Monday, 03 August, 2009 07:08
> This succeed with "ssleay32.dll v0.9.8.4" and it fails with
> "ssleay32.dll v0.9.8.11".
> 2009-08-03 13:40:25,911 DEBUG
> [org.apache.tomcat.util
.4" and it fails with
"ssleay32.dll v0.9.8.11".
Server Log:
==
2009-08-03 13:40:25,911 DEBUG
[org.apache.tomcat.util.net.PoolTcpEndpoint] Handshake failed
javax.net.ssl.SSLException: Unexpec
3 13:40:25,911 DEBUG
[org.apache.tomcat.util.net.PoolTcpEndpoint] Handshake failed
javax.net.ssl.SSLException: Unexpected end of handshake data
at
com.sun.net.ssl.internal.ssl.HandshakeInStream.read(HandshakeInStream.java:81)
at java.io.InputStream.read(InputStream
function.
- The problem is, that the function SSL_get_peer_certificate() returns
NULL, if the handshake failed, even if the server has sent a certificate.
So is there an easy way, to pass on the tested certificate from the
callback function?
I've tried to store the certificate in an extra data
SSL was working but I wasn't able to access SSL_CLIENT variables (like
SSL_CLIENT_S_DN_Email). I added the directive 'SSLVerifyClient
optional_no_ca' to my .htaccess file and now the variables are available.
However, in IE the page loads normally the first time but after several
refreshes I get th
If you wouldn't mind moving over to "not-yet-common-ssl" mailing list
(SSL and Java) I might be able to help you over there:
http://lists.juliusdavies.ca/listinfo.cgi/not-yet-commons-ssl-juliusdavies.ca/
To me it looks like you are missing a client certificate.
Try using "java -jar not-yet-comm
SSL socket.
com.vitria.connectors.http.HttpTargetConnector.getSSLSocket(HttpTargetConnector.java:575)
--- The linked exception is ---
java.net.SocketException: Xport: SSL handshake failed: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
com.vitria.roi.javanative.VTSocketImpl.connect(VTSocketImp
On Sun, Apr 17, 2005 at 10:53:50PM, Asif Iqbal wrote:
> Hi All
>
> I installed Apache/1.3.33 (Unix) mod_perl/1.29 mod_ssl/2.8.22
> OpenSSL/0.9.7d on Solaris
Upgrade OpenSSL to latest to fix the problem. Thanks
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
"..there are two kinds of pe
have been transferred
The Apache error log says:
[Sun Apr 17 22:35:21 2005] [error] mod_ssl: SSL handshake failed (server
my.website.com:443, client 192.168.0.15) (OpenSSL library error follows)
[Sun Apr 17 22:35:21 2005] [error] OpenSSL: error:1409D08A:SSL
Hi. Customer using Apache HTTP on AS/400 V5R2. Getting loads of error
logs with the above error. What is causing this problem. Not too au faut
with Apache. What can we do to get a clearer picture on what is causing
this problem. Any assistance would be greatly appreciated!!
Thanks a ton.
Le
client certificates of the Netscape Certificate
Server in the directory conf/ssl.crt ?
Regards,
Ravi APPANAH
- Original Message -
From: "Owen Boyle" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 26, 2001 10:40 AM
Subject: Re: URGENT : SSL Hand
client certificate B[23/jan/2001 17:22:52 14800]
[trace] OpenSSL: Exit: error in SSLv3 read client certificate B[23/jan/2001
17:22:52 14800] [error] SSL handshake failed (server cerbereweb.anpe.fr:843,
client 10.0.144.161) (OpenSSL library error follows)[23/jan/2001 17:22:52
14800] [error] Ope
, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED]
-Original Message-
From: drt rappanah [mailto:[EMAIL PROTECTED]]
Sent: 25 January 2001 14:07
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: URGENT : SSL Handshake failed
Importance: High
Hi
od_ssl:
Certificate Verification: Error (20): unable to get local issuer
certificate[Tue Jan 23 13:21:14 2001] [error] mod_ssl: SSL handshake failed
(server cerbereweb.anpe.fr:843, client 10.0.144.161) (OpenSSL library error
follows)[Tue Jan 23 13:21:14 2001] [error] OpenSSL
oblem.
(al the win32 browsers had no problems at all)
Apache error:
[error] mod_ssl: SSL handshake failed (server myserver.net:443,
client 195.38.232.12) (OpenSSL library error follows)
[error] OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure
This is on Apac
50 matches
Mail list logo
