Why aren't you fixing your library, instead of pushing workarounds into open
source? Is there some other vulnerability that you're trying to avoid, or is
it a strict compatibility issue? If it's strictly for proprietary
compatibility, then you need to get the proprietary vendor to fix its
Is this the F5 BigIP needs padding bug? Tried to follow all the discussion
threads and got lost.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
On Tue, Sep 02, 2014 at 10:52:59PM +0300, Artem Pylypchuk wrote:
Yes, the stuck connection bug I mentioned is the F5 BigIP needs padding
bug or is very similar to it.
Sorry for the confusing explanation.
To disable TLSv1.2 with the associated ciphers and extensions (which
increase the size
OpenSSL is telling me to do.
Date: Tue, 7 Feb 2012 19:47:59 +0100
From: st...@openssl.org
To: jetso...@hotmail.com
Subject: Re: Renegotiation
On Tue, Feb 07, 2012, Jason Schultz wrote:
Dr. Henson-
I've sent this question to the OpenSSL mailing list, but have not received
any
My apologies for accidently spamming the list with this message, my web based
email was having issues.
I am still unable to successfully rehandshake in the scenario below, and was
wondering if anyone might have some ideas. Is this the proper list for this
email?
Thanks.
From:
Thanks Jakob,
Callback is a possibility but the limitation is that this callback does not
have access to the filename (which can change for every client) to load all
pem files. Also I do not want to read the file every time in call back.
I was ablt to prototype my idea by recreating the SSL
Your callback should have access to the Global data in your program,
which can include both that file name and variables to hold on to the
loaded PEM file once loaded by the first session needing it.
On 12/2/2011 12:09 PM, Rohit Bansal wrote:
Thanks Jakob,
Callback is a possibility but the
On 12/1/2011 6:33 PM, Rohit Bansal wrote:
Hi,
Let me start with a disclaimer that i am not very experienced with
openssl.
I have a requirement. In an enterprise all clients and servers
communicate over ssl. the certs in client and server are self signed.
There is one client application
On Fri, 2010-01-29 at 01:52 +0100, Dr. Stephen Henson wrote:
On Thu, Jan 28, 2010, Adam Grossman wrote:
hello,
so close, yet so far
i fixed it where the client is sending the it's certs over and the
handshake is complete. but i have two problems:
1. for different
To: openssl-users@openssl.org
Subject: RE: renegotiation with client certificate
i just tried 0.9.7m, and to no avail. i double checked my certs, i made
sure my CA cert on the server is correct, and i am still getting the
same error on the server and the browser is giving to Peer does
On Thu, Jan 28, 2010, Adam Grossman wrote:
hello,
so close, yet so far
i fixed it where the client is sending the it's certs over and the
handshake is complete. but i have two problems:
1. for different clients, i have different CA certs. so i load them all
up when the server
nevermind... i had blinders on while reading the error, and i just
concentrated on the server. i just noticed the browser says:
Peer does not recognize and trust the CA that issued your certificate.
so i need to go make sure my certs are set up properly.
thanks,
-=- adam grossman
On Wed,
I recently had the same issue that was resolved when I changed Apache to use
0.9.7k.
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Adam Grossman
Sent: Wednesday, January 27, 2010 5:01 PM
To: openssl-users@openssl.org
i just tried 0.9.7m, and to no avail. i double checked my certs, i made
sure my CA cert on the server is correct, and i am still getting the
same error on the server and the browser is giving to Peer does not
recognize and trust the CA that issued your certificate.
thanks,
-=- adam grossman
On
of the setup ?
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Adam Grossman
Sent: Wednesday, January 27, 2010 9:37 PM
To: openssl-users@openssl.org
Subject: RE: renegotiation with client certificate
i just tried 0.9.7m
, 2010 9:37 PM
To: openssl-users@openssl.org
Subject: RE: renegotiation with client certificate
i just tried 0.9.7m, and to no avail. i double checked my certs, i made
sure my CA cert on the server is correct, and i am still getting the
same error on the server and the browser is giving
-users@openssl.org
Subject: RE: Renegotiation with reader and writer threads.
My client and server has two threads each: a reader thread and a writer
thread.
I have put the renegotiation code in the reader thread. It works for
most of the time but occasionally the client gets an Encrypted Alert
I'm not sure what you mean by reader and writer, but if you mean
that both threads call OpenSSL functions, you will need to associate a
mutex with each connection to ensure that the reader thread and
writer thread are not trying to manipulate that SSL connection at the
same time.
The reader
] On Behalf Of Kumar, Sunil
Sent: Tuesday, February 08, 2005 6:30 AM
To: openssl-users@openssl.org
Subject: RE: Renegotiation with reader and writer threads.
I'm not sure what you mean by reader and writer, but
if you mean
that both threads call OpenSSL functions, you will need to
associate
Now coming to the first part of your comment. As I understand it, the
manipulation of SSL connection
needs mutex, but can the SSL_read(s) and SSL_write(s) be done from two
threads independently?
It can be done from two threads, but it requires a mutex. Thus the two
threads are not
My client and server has two threads each: a reader thread and a writer
thread.
I have put the renegotiation code in the reader thread. It works for most
of the time but occasionally the client gets an Encrypted Alert message
( I suspect that this happens when the application data somehow gets
To: [EMAIL PROTECTED]
Subject: Re: renegotiation in 0.9.7
On Mon, Jan 27, 2003 at 03:21:45PM -, Nigel Spowage wrote:
okay, so the proper way to renegotiate a connection is :
1 - call SSL_renegotiate()
2 - call SSL_do_handshake()
3 - wait for either
3a
On Thu, Jan 30, 2003 at 10:41:08AM -, Nigel Spowage wrote:
my client app calls SSL_renegotiate() and gets a return value of 1
(success i presume, as i cann't find a man page for this
function). this sets up internal flags in ssl ready to negotiate the
connection.
i call
To guess what is going on, I'd have to know
- whether your application is operating as a client or a server
(an SSL/TLS client apparently) and
yep, it's a client. is the renegotiation code different for a client than for a server
?
- what protocol version is used.
SSL 2.0 does not
On Mon, Jan 27, 2003 at 03:21:45PM -, Nigel Spowage wrote:
okay, so the proper way to renegotiate a connection is :
1 - call SSL_renegotiate()
2 - call SSL_do_handshake()
3 - wait for either
3a- SSL_renegotiate_pending() to return 0, or
3b- an acceptable amount of time (which means
On Mon, Jan 27, 2003 at 10:33:44AM -, Nigel Spowage wrote:
i'm currently trying to implement ssl renegotiation for an
application which uses openssl in a non-blocking mode.
SSL_renegotiate(ssl);
result = SSL_do_handshake(ssl);
/* result is okay at this point */
/* my app waits for a
am i missing something ? is there something extra i need to do ?
Yes, call SSL_renegotiate() to initiate a second handshake once the
first one has finished. Otherwise SSL_do_handshake() does not think
that there is something to do for it.
okay, so the proper way to renegotiate a
On Fri, Jul 30, 1999 at 08:15:01AM +0200, Holger Reif wrote:
What signals a key renegotiation during a SSL session? Do Nav/IE typically
renegotiate session keys?
Yes, in case a client cret is requested later by the server
(depending on the URL requested) and ibn case of Global
ServerID
otherwise you get busy waiting. (I'm not even sure that s_client
is
correct in this respect, but it's to confusingly written to deeply
look into this issue.)
_
Bodo,
Good point, since as far as most users are concerned s_client.c and
s_server.c are the most referenced
29 matches
Mail list logo
