> So the question is whether it is legal for the server to send data while
> renegotiation is in progress?
The server is not supposed to be required to track whether
renegotiation is
in progress or not. If you try to send data while a renegotiation is in
progress, the OpenSSL library is
In message <[EMAIL PROTECTED]> on Wed, 21 Jun 2006 10:44:33 +0900, Tatsuya
Tsurukawa <[EMAIL PROTECTED]> said:
Tsurukawa.Tatsuya> It seems I need to clear error queue after private
Tsurukawa.Tatsuya> decryption error, but does the status of error
Tsurukawa.Tatsuya> queue actually affect to the be
> Perhaps the backtracking to reprocess the event as data involves a
> second blocking socket read() in ssl3_read_bytes(). I am not familiar
> with the details of this code. What I am curious about is when does
> this happen. What is it exactly that the server is doing here, why,
> and is it legal?
On Tue, Jun 20, 2006 at 07:50:24PM -0700, David Schwartz wrote:
> You could argue that we could just fix this and deprecate "fake
> non-blocking I/O" for future major versions. The argument would be that this
> won't break any application that's not broken already and might fix existing
> applicat
One more point, and then I'll try to shut up. ;)
You could argue that we could just fix this and deprecate "fake
non-blocking I/O" for future major versions. The argument would be that this
won't break any application that's not broken already and might fix existing
applications.
> You are now introducing some weirdness into our little blocking world.
> Threads and other scary stuff. Yes, if a gremlin reads the data from the
> buffer between calls to select() and read(), the read() call
> might block.
> But if we assume that there is only one process with single thread us
> > R. Stevens, Unix Network Programming, Volume 1, Second Edition, Section
> > 6.3, page 153:
> >
> > 1. A socket is ready for reading if any of the following four conditions
> > is true:
> >
> > a. The number of bytes of data in the socket receive buffer is greater
> > than or equal to the curren
Dear Richard,
Thank you for your quick answer.
I did nothing after RSA_private_decrypt() error(-1) with a wrong private
key and called ERR_get_error() right after BIO_new_mem_buf() returned NULL
as follows.
iRet = RSA_private_decrypt(); // provide wrong private key
if( iRet == -1 ){
//
Hello,
> > > If anyone thinks that 'select' or 'poll' guarantees that a future
> > > operation
> > > will not block, even if it's a single operation, that's just plain not
> > > true.
> > > The only way you can guarantee that even one operation will not block is
> > > if
> > > you set the sock
> Linux:
> Three independent sets of descriptors are watched. Those listed in
> readfds will be watched to see if characters become available for read-
> ing (more precisely, to see if a read will not block - in particular, a
> file descriptor is also ready on end-of-file)
You'll
> > If anyone thinks that 'select' or 'poll' guarantees that a
> > future operation
> > will not block, even if it's a single operation, that's just
> > plain not true.
> > The only way you can guarantee that even one operation will not
> > block is if
> > you set the socket non-blocking.
> R
> > If anyone thinks that 'select' or 'poll' guarantees that a future
> > operation
> > will not block, even if it's a single operation, that's just plain not true.
> > The only way you can guarantee that even one operation will not block is if
> > you set the socket non-blocking.
>
> Really.
David Schwartz wrote:
My first reaction was that this is a bug in the library, but I
didn't feel
very strong about it and would have accepted that this is just a bug in
s_client. I like your argument about the library not having the right to
make 2 blocking calls unless retry is set and now I'm
> My first reaction was that this is a bug in the library, but I
> didn't feel
> very strong about it and would have accepted that this is just a bug in
> s_client. I like your argument about the library not having the right to
> make 2 blocking calls unless retry is set and now I'm back to think
Mikhail Kruk wrote:
I'm pretty confident that the fix (if it is feasible) is not going to
break any correct application code.
And I'm pretty confident that it is going to make app. engineer's life
easier.
My view comes from what is architecturally scalable by design which
makes it recursive
> > Well, if s_client is broken in the blocking mode maybe it should be
> > removed completely. I did test it in the non-blocking mode and, of
> > course, it does not have the described error.
>
> So are you saying the bug is:
>
> * in s_client (for not correctly handling the SSL layer APIs)
Mikhail Kruk wrote:
It is unclear to me if Marek
thinks this problem is due to a library bug or simply that s_client
should be clearing SSL_MODE_AUTO_RETRY in its block socket use case for
that program. We all know that OpenSSL s_client has a command line
option to enable nonblocking mode so
> If I understand correctly the original thread poster was explaining a
> bug in using OpenSSL s_client triggered during a renegotiation (was this
> client or server initiated? SGC related?).
- client sends some data
- server initiates renegotiation and immediately after that sends some
data
Dow! Ignore my post.
My system and the one of openssl-0.9.8b I am using have
different sized structures and part of my code (a sub-library) wasn't
building against it. Probably Fedora removing legally problematic code.
Darryl
__
Sorry to come at this thread a week later.
I can see both sides of the problem here, there are infact three
distinct modes of operation:
Non-Blocking: There is where the underlying socket descriptor is in
non-blocking mode. SSL API calls return -1 and set SSL_get_errno() to
allow for EAGA
I have some code what was originally doing:
HMAC_CTX ctx;
HMAC_Init(&ctx, key, keylen, EVP_md5());
HHAC_Update(&ctx, data, datalen);
HHAC_Update(&ctx, moredata, moredatalen);
HMAC_Final(&ctx, digest, &digestlen);
This seems to work fine and valgrind indicates there are no memory
leaks, i.e
In message <[EMAIL PROTECTED]> on Tue, 20 Jun 2006 21:16:49 +0900, Tatsuya
Tsurukawa <[EMAIL PROTECTED]> said:
Tsurukawa.Tatsuya> bioPtr = BIO_new_mem_buf( InputPEMstring, -1 );
Tsurukawa.Tatsuya> :
Tsurukawa.Tatsuya> prvkey = PEM_read_bio_RSAPrivateKey( bioPtr, NULL, NULL,
NULL );
Tsurukawa.T
Hi all,
I have written a program which does RSA_private_decrypt() repeatedly with
a private key given with PEM format.
I also derive private key with BIO_new_mem_buf() and
PEM_read_bio_RSAPrivateKey()
functions, so the brief code is as follows.
bioPtr = BIO_new_mem_buf( InputPEMstring, -1 );
Hello Larry,
OpenSSL message digest implementations trigger
bug[s] in code optimizer in gcc 3.3 for sparc64. So this fails to complete
RIPEMD160 test. It is already addressed as Bugs in gcc triggered Section
in ./PROBLEMS file of openssl Souce release.
The recommendation is to upgrade yo
24 matches
Mail list logo