strange problem decrypting a file -- EVP_DecryptFinal

[Chris Rex]

Greetings, users.

I am having a strange problem decrypting a file that I used openssl to
encrypt via the following:
openssl enc -bf -in nfoz.tar.gz -out nfoz.tar.gz.bf

If I attempt to decrypt with the following:
openssl enc -d -bf -in nfoz.tar.gz.bf -out nfoz.tar.gz

I get the following message if I type anything but the correct passphrase:
46462:error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_enc.c:450:

If I type the correct passphrase, I get this error message:
46489:error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_enc.c:457:

The line numbers (450 and 457) always seem to be 7 lines apart, depending on
the version of openssl I attempt to decrypt the file with.

The file is -rw-r--r--  1 phiz  www  37081488 May 17 19:01 nfoz.tar.gz.bf

The code in question appears to be this:

if (b > 1)
   {
   if (ctx->buf_len || !ctx->final_used)
   {

EVPerr(EVP_F_EVP_DECRYPTFINAL_EX,EVP_R_WRONG_FINAL_BLOCK_LENGTH);
   return(0);
   }
   OPENSSL_assert(b <= sizeof ctx->final);
   n=ctx->final[b-1];
   if (n == 0 || n > (int)b)
   {
   EVPerr(EVP_F_EVP_DECRYPTFINAL_EX,EVP_R_BAD_DECRYPT);
   return(0);
   }
   for (i=0; ifinal[--b] != n)
   {
   EVPerr(EVP_F_EVP_DECRYPTFINAL_EX,EVP_R_BAD_DECRYPT);
   return(0);
   }
   }
   n=ctx->cipher->block_size-n;
   for (i=0; ifinal[i];
   *outl=n;
   }
else
   *outl=0;
return(1);
}

I am stumped, (and an idiot for not having a good backup).  Any help would
be very appreciated.

Thanks in advance,

Chris

RE: Multi-threaded SSL Socket Usage

[Williams Bryn-R40716]

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Armstrong
Sent: Thursday, 17 May 2007 7:50 PM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage

In addition to the reply given below; I have a few follow-up questions
after reading some threads from mail-archive.com

Specifically;
http://www.mail-archive.com/openssl-users@openssl.org/msg46239.html

What's going on here?

If I receive WANT_READ, during an SSL_write - what does it want me to
actually do?

Does it want me to perform SSL_read? Or just 'select' the socket and
wait until it becomes readable; at which point, I then just write again?

Can someone please make it painfully clear on what exactly is expected
of the application when receiving these events.

Thanks,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Armstrong
Sent: Thursday, 17 May 2007 8:13 PM
To: openssl-users@openssl.org
Subject: FW: Multi-threaded SSL Socket Usage

Resend; it's been a few hours and my reply below has yet to come
through.

- Andrew

-Original Message-
From: Andrew Armstrong [mailto:[EMAIL PROTECTED]
Sent: Thursday, 17 May 2007 6:49 PM
To: 'openssl-users@openssl.org'
Subject: RE: Multi-threaded SSL Socket Usage

Thanks for your response David, Rodney.

I understand (clearer now) the requirement that:

* If SSL_read reports WANT_WRITE; we need to issue an immediate
SSL_write However; what do I actually write? Do I write a blank/empty
string (SSL_write(ssl, "", 0)?) - I may not have anything to write.
Please confirm?

* If SSL_read reports WANT_READ; re-try the read, before issuing an
SSL_write before the retry of the read. Please confirm?

* If SSL_write reports WANT_WRITE; re-try the write immediately, without
issuing an SSL_read before the retry of the write. Please confirm? 

* If SSL_write reports WANT_READ; issue an SSL_read on the socket before
issuing an SSL_write. Once the READ has been done, re-do the SSL_write.
Please confirm?

Additionally; the logic to selecting sockets for reading should be:

* If the readfd of the socket is set (via select()) OR
* The socket has reported WANT_READ from an operation

Can you please provide your thoughts on the above logic?

Many thanks for the help so far.

Regards,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Wednesday, 16 May 2007 3:19 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> The design of the application is that there are worker threads which 
> pick up data and send them out via the sockets. This works for the 
> most part, however as mentioned it will sometimes no longer appear to 
> work (data is not received in a timely fashion for example). I would 
> think this is just do to how complex the read/write logic is for 
> openssl, nonblocking multi-threaded applications.

The most common non-obvious cause of this problem is failure to retry an
operation even though something changed after the last time you tried
it. It is important to retry all operations any time you make any
forward progress, not just the operation you think you made forward
progress on.

For example, here's a common way you can deadlock:

Assume that your side is supposed to send next and the other side won't
send any data until you do. The other side has just sent some
negotiation data but you haven't received it yet. You can't send any
data until you get it.
Now imagine this happens:

1) You call SSL_write, you get a 'WANT_READ' indication because the
negotiation data has not arrived yet.

2) The negotiation data arrives on the socket.

3) You call SSL_read and it returns 'WANT_READ' because the negotiation
data gave it no application data. It has now read the negotiation data.

4) You select for readability on the socket because both SSL_write and
SSL_read failed. You do not call SSL_read or SSL_write again until
select tells you to.

You are now deadlocked. You will not retry SSL_write until you read some
data. But the data you are waiting for has already arrived and been read
(in the call to SSL_read).

You must think very carefully about what the return values mean and
retry all operations (read and write) any time there's any chance that
forward progress has been made.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[Andrew Armstrong]

Thanks David.

>The deadlock scenario can only occur when you refuse to call SSL_read until
>you find the socket in the read set from select. So you must be careful
>under what circumstances you decide to get into this state.

So under which circumstances should an SSL_read be performed on a socket? My
list is currently:
* The socket is readable via select()
* The socket returned WANT_READ from a previous SSL_read or SSL_write
operation
* Should I call SSL_pending on the instance instead and use this as a flag
to see if data is available? Is this resource intensive etc?

Is that all I need to worry about/is it correct to know when a read should
be performed? If you could tick or cross (or add!) those ideas that would be
great.

I am still a bit unclear on how you respond to a WANT_READ/WANT_WRITE error;
as you mention select()ing the socket as well as then performing an SSL_read
(but never an SSL_write) in response to it.

Here's some pseudo code to represent the logic I am thinking of at the
moment in response to the possible scenarios:

// Receiving WANT_READ during an SSL_write
bool writeSuccess = false;
while (!writeSuccess) {
ret = SSL_write(...)

if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) { 
// Wants a write, just re-try the operation.
Continue;
}

if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
// Socket requires it be readable prior to performing the
write.
// Block until the socket is readable
Select(socket, readfds);

// Socket is readable by now, re-try the SSL_write
// without needing to call SSL_read
continue;
}
...
}

// Receiving WANT_READ during an SSL_read
while (true) {
ret = SSL_read(...)

if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
// Re-try the SSL_read
continue;
}

if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) {
// Socket wants to be writable before reading
// Block until the socket is writable
select(socket, writefds);

// Socket is writable by now, re-try
// the read without needing to call SSL_write
continue;
}
...
}

Can you please comment on the above pseudo code to see whether this logic is
correct? Of importance is the way I would just have the read/write process
block (should I block?) on select() until the socket is readable/writable,
and when it is as per the error message, run the SSL_read/SSL_write process
again.

Thanks,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Friday, 18 May 2007 6:20 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> So long as your last operation, SSL_read or SSL_write, returned WANT_READ,
> there is no reason to retry that particular operation until you find the
> socket in the read set.

Ack! Sorry part was badly worded. There is no reason to retry that
particular operation until you either find the socket in the read set or
perform some other operation that might read from the socket.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[Andrew Armstrong]

Thanks David.

>The deadlock scenario can only occur when you refuse to call SSL_read until
>you find the socket in the read set from select. So you must be careful
>under what circumstances you decide to get into this state.

So under which circumstances should an SSL_read be performed on a socket? My
list is currently:
* The socket is readable via select()
* The socket returned WANT_READ from a previous SSL_read or SSL_write
operation
* Should I call SSL_pending on the instance instead and use this as a flag
to see if data is available? Is this resource intensive etc?

Is that all I need to worry about/is it correct to know when a read should
be performed? If you could tick or cross (or add!) those ideas that would be
great.

I am still a bit unclear on how you respond to a WANT_READ/WANT_WRITE error;
as you mention select()ing the socket as well as then performing an SSL_read
(but never an SSL_write) in response to it.

Here's some pseudo code to represent the logic I am thinking of at the
moment in response to the possible scenarios:

// Receiving WANT_READ during an SSL_write
bool writeSuccess = false;
while (!writeSuccess) {
ret = SSL_write(...)

if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) { 
// Wants a write, just re-try the operation.
Continue;
}

if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
// Socket requires it be readable prior to performing the
write.
// Block until the socket is readable
Select(socket, readfds);

// Socket is readable by now, re-try the SSL_write
// without needing to call SSL_read
continue;
}
...
}

// Receiving WANT_READ during an SSL_read
while (true) {
ret = SSL_read(...)

if (ssl_Error(ret) == SSL_ERROR_WANT_READ) {
// Re-try the SSL_read
continue;
}

if (ssl_Error(ret) == SSL_ERROR_WANT_WRITE) {
// Socket wants to be writable before reading
// Block until the socket is writable
select(socket, writefds);

// Socket is writable by now, re-try
// the read without needing to call SSL_write
continue;
}
...
}

Can you please comment on the above pseudo code to see whether this logic is
correct? Of importance is the way I would just have the read/write process
block (should I block?) on select() until the socket is readable/writable,
and when it is as per the error message, run the SSL_read/SSL_write process
again.

Thanks,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Friday, 18 May 2007 6:20 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> So long as your last operation, SSL_read or SSL_write, returned WANT_READ,
> there is no reason to retry that particular operation until you find the
> socket in the read set.

Ack! Sorry part was badly worded. There is no reason to retry that
particular operation until you either find the socket in the read set or
perform some other operation that might read from the socket.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: New version of OpenSSL not recognised by OS

[Keith Thompson]

On Thu 07-05-17 00:57, Leslie Katz wrote:
> I'm using Fedora Core 3.
> 
> I intermittently run a program called Rootkit Hunter and, each time I
> do, it complains that I'm using an old version of OpenSSL (v 0.9.7a).

Have you considered updating your OS?  Fedora Core 6 includes OpenSSL
0.9.8b.

-- 
Keith Thompson <[EMAIL PROTECTED]>  San Diego Supercomputer Center
  858-822-0853
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[David Schwartz]

> So long as your last operation, SSL_read or SSL_write, returned WANT_READ,
> there is no reason to retry that particular operation until you find the
> socket in the read set.

Ack! Sorry part was badly worded. There is no reason to retry that
particular operation until you either find the socket in the read set or
perform some other operation that might read from the socket.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: New version of OpenSSL not recognised by OS

[Victor Duchovni]

On Thu, May 17, 2007 at 12:57:29PM -0700, Leslie Katz wrote:

> Thanks for your reply, Jan.
> 
> The result of "which openssl" is "/usr/bin/openssl".
> 
> The result of "/usr/local/bin/openssl" is "No such file or directory".
> 
> You say "installing a newer version will not help you anyway since system 
> commands dependent on OpenSSL will stay dependent on the version shipped 
> with the system."
> 
> Does that mean I can't even try to replace 0.9.7a with 0.9.7m?

The 0.9.7x releases maintain binary compatibility (there was an "i"
or "j" IIRC release that broke it by accident and an update was issued).

You should be able to replace the 0.9.7a runtime with a 0.9.7m runtime,
and should probably do it to avail yourself of the bug and security
fixes. Ideally the vendor has updated binary packages available.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

New version of OpenSSL not recognised by OS

[Leslie Katz]

Thanks for your reply, Jan.

The result of "which openssl" is "/usr/bin/openssl".

The result of "/usr/local/bin/openssl" is "No such file or directory".

You say "installing a newer version will not help you anyway since system 
commands dependent on OpenSSL will stay dependent on the version shipped 
with the system."

Does that mean I can't even try to replace 0.9.7a with 0.9.7m?

Thanks again,

Leslie
 

Visit http://stumblng.tumblr.com
An Australian lawyer's tumblelog about things (some legal, most not) you might 
otherwise have missed

- Original Message 
From: Jan Pechanec <[EMAIL PROTECTED]>
To: openssl-users@openssl.org
Sent: Thursday, 17 May, 2007 6:10:44 PM
Subject: Re: New version of OpenSSL not recognised by OS

On Thu, 17 May 2007, Leslie Katz wrote:

>I re-ran Rootkit Hunter and it still complained about my having the old
>version. I ran "openssl version" and that gave me the old version
>number too.

system shipped OpenSSL in Fedore is probably in /usr/bin, /usr/lib 
etc. When installing from source code, default location is /usr/local/...

run 'which openssl'
run '/usr/local/bin/openssl version'

installing a newer version will not help you anyway since system 
commands dependent on OpenSSL will stay dependent on the version shipped 
with the system.

you cannot copy newer libs over old ones since 0.9.7 branch is not 
binary compatible with 0.9.8 one.

Jan.

-- 
Jan Pechanec
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]





  
___
How would you spend $50,000 to create a more sustainable environment in 
Australia?  Go to Yahoo!7 Answers and share your idea.
http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[David Schwartz]

> Thanks for your response David, Rodney.
>
> I understand (clearer now) the requirement that:
>
> * If SSL_read reports WANT_WRITE; we need to issue an immediate SSL_write
> However; what do I actually write? Do I write a blank/empty string
> (SSL_write(ssl, "", 0)?) - I may not have anything to write.
> Please confirm?

No. WANT_WRITE means that SSL_read cannot make further progress until some
data can be written to the socket. SSL_write is for encrypting platintext.

> * If SSL_read reports WANT_READ; re-try the read, before issuing an
> SSL_write before the retry of the read. Please confirm?

If SSL_read reports WANT_READ, it means it cannot make further progress
until some data is read from the socket.

> * If SSL_write reports WANT_WRITE; re-try the write immediately, without
> issuing an SSL_read before the retry of the write. Please confirm?

Huh?

> * If SSL_write reports WANT_READ; issue an SSL_read on the socket before
> issuing an SSL_write. Once the READ has been done, re-do the SSL_write.
> Please confirm?

It sounds like you are all mixed up.

1) Both SSL_read and SSL_write can both read and write to or from the
socket.

2) A WANT_READ indication means further progress cannot be made until data
can be read from the socket.

3) A WANT_WRITE indication means further progress cannot be made until data
can be written to the socket.

> Additionally; the logic to selecting sockets for reading should be:
>
> * If the readfd of the socket is set (via select())
> OR
> * The socket has reported WANT_READ from an operation

> Can you please provide your thoughts on the above logic?

You can call SSL_read on a non-blocking socket any time you want. It's
always safe, since it can never block. The deadlock scenario can only occur
when you refuse to call SSL_read until you find the socket in the read set
from select. So you must be careful under what circumstances you decide to
get into this state.

So long as your last operation, SSL_read or SSL_write, returned WANT_READ,
there is no reason to retry that particular operation until you find the
socket in the read set.

> If I receive WANT_READ, during an SSL_write - what does it want me to
> actually do?

This means that SSL_write cannot accept any more data from you until it
reads some data from the socket. It doesn't particularly care what you do
about it.

You can call SSL_write again immediately. Maybe the data just arrived. You
could add the socket to the 'read' set and retry the SSL_write when you get
a read hit.

You have one piece of information, no further data can be encrypted and send
on this connection until some data is read from the socket. Note that *any*
call to SSL_read or SSL_write with *any* return value potentially
invalidates this knowledge (they can all read *this* data from the socket
and still fail). (Obviously, if SSL-write again returns WANT_READ, that
doesn't invalidate it.)

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: How to get rid of this message :"Enter PEM pass phrase" ?

[Rajat Dudeja]

>> 1. rpm -e openssl ( to install the already installed openssl-0.9.8b)

>1) reinstall openssl package that came with Fedora. unless you are going
>to rebuild all the packages that depend on it you will face a nightmare

>2) strip off the password from your .pem file - if you really dont want
to
>manually type in the password.  there are plenty of guides about doing
>this - mostly for those people with openssl certs for their apache for
>example

alan
_



Hi Alan ! thanks for the suggestions and help.

Rajat

Application Crash: Need Some Inputs

[Prabhu S]

Hi All,

My SSL enabled client application creates threads as per some configuration.
On creating as many as about 400+ threads simultaneously the application
crashes. Each thread as its own openSSL context object 'ctx' and ssl object
'ssl' [ SSL_CTX   *ctx; SSL   *ssl;].

The stack trace from the crash core is :

#0  0xe410 in __kernel_vsyscall ()
#1  0x0030a1f8 in raise () from /lib/libc.so.6
#2  0x0030b948 in abort () from /lib/libc.so.6
#3  0x0033f52a in __libc_message () from /lib/libc.so.6
#4  0x00345424 in _int_free () from /lib/libc.so.6
#5  0x0034595f in free () from /lib/libc.so.6
#6  0x40542192 in CRYPTO_free () from ../lib/libcrypto.so.0.9.8
#7  0x40542168 in CRYPTO_free () from ../lib/libcrypto.so.0.9.8
#8  0x405ac77a in ERR_clear_error () from ../lib/libcrypto.so.0.9.8
#9  0x40955248 in ?? ()
#10 0x002d6d30 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#11 0x4039e1b2 in SSL_CTX_use_certificate_chain_file () from
../lib/libssl.so.0.9.8
#12 0x409701f0 in ?? ()
#13 0x007d0f00 in ?? ()
#14 0x41c0c3f8 in ?? ()
#15 0x403ff188 in SslTransactionHandler::loadCerts (this=0x2d6d20) at
SslTransactionHandler.cpp:715
Previous frame inner to this frame (corrupt stack?)

Any idea why while the function SSL_CTX_use_certificate_chain_file () is
being called there is a crash. All threads would be calling the function.

The crash is intermittent. Most of the times there are no issues.

Thanks and Regards,
Prabhu. S

Re: Openssl crashing

[Marek Marcola]

Hello,
> I have a problem where my imap server (dovecot) is crashing inside
> openssl when getting APPEND requests from the Mac mail client:
> 
> #0  0x00419fbc in tls1_mac ()
> #1  0x0042e25b in ssl3_read_bytes ()
> #2  0x0042bcb4 in ssl3_read ()
> #3  0x00407dc8 in ssl_read (proxy=0x643000) at ssl-proxy-
> openssl.c:395
> #4  0x00407e39 in ssl_step (context=Variable "context" is not
> available.
> ) at ssl-proxy-openssl.c:440
> #5  0x00410209 in io_loop_handler_run (ioloop=0x639fa0) at
> ioloop-poll.c:199
> #6  0x0040f6da in io_loop_run (ioloop=0x639fa0) at ioloop.c:326
> #7  0x00406792 in main (argc=1, argv=0x7fbc08,
> envp=0x7fbc18) at main.c:432
> 
> It happens with both 0.9.7a and 0.9.8e. I'll recompile ssl with "-g" but
> in the mean time I have two questions:
> 
> 1. Is openssl guaranteed not to segfault even with invalid data from the
> remote client?
No (as any other software).

> 2. I had already specified  -DTLS_DEBUG when compiling openssl but
> nothing appears in the logs. How do I get the debug data to appear in a
> file? I have the source to dovecot.
This additional messages are printed on stderr (or stdout - I do not
remember exactly).

Best regards,
-- 
Marek Marcola <[EMAIL PROTECTED]>

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Openssl crashing

[John Rowe]

I have a problem where my imap server (dovecot) is crashing inside
openssl when getting APPEND requests from the Mac mail client:

#0  0x00419fbc in tls1_mac ()
#1  0x0042e25b in ssl3_read_bytes ()
#2  0x0042bcb4 in ssl3_read ()
#3  0x00407dc8 in ssl_read (proxy=0x643000) at ssl-proxy-
openssl.c:395
#4  0x00407e39 in ssl_step (context=Variable "context" is not
available.
) at ssl-proxy-openssl.c:440
#5  0x00410209 in io_loop_handler_run (ioloop=0x639fa0) at
ioloop-poll.c:199
#6  0x0040f6da in io_loop_run (ioloop=0x639fa0) at ioloop.c:326
#7  0x00406792 in main (argc=1, argv=0x7fbc08,
envp=0x7fbc18) at main.c:432

It happens with both 0.9.7a and 0.9.8e. I'll recompile ssl with "-g" but
in the mean time I have two questions:

1. Is openssl guaranteed not to segfault even with invalid data from the
remote client?

2. I had already specified  -DTLS_DEBUG when compiling openssl but
nothing appears in the logs. How do I get the debug data to appear in a
file? I have the source to dovecot.


Thanks for your help.

John


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[Andrew Armstrong]

Thanks for your response David, Rodney.

I understand (clearer now) the requirement that:

* If SSL_read reports WANT_WRITE; we need to issue an immediate SSL_write
However; what do I actually write? Do I write a blank/empty string
(SSL_write(ssl, "", 0)?) - I may not have anything to write. Please confirm?

* If SSL_read reports WANT_READ; re-try the read, before issuing an
SSL_write before the retry of the read. Please confirm?

* If SSL_write reports WANT_WRITE; re-try the write immediately, without
issuing an SSL_read before the retry of the write. Please confirm? 

* If SSL_write reports WANT_READ; issue an SSL_read on the socket before
issuing an SSL_write. Once the READ has been done, re-do the SSL_write.
Please confirm?

Additionally; the logic to selecting sockets for reading should be:

* If the readfd of the socket is set (via select())
OR
* The socket has reported WANT_READ from an operation

Can you please provide your thoughts on the above logic?

Many thanks for the help so far.

Regards,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Wednesday, 16 May 2007 3:19 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> The design of the application is that there are worker threads which
> pick up data and send them out via the sockets. This works for the most
> part, however as mentioned it will sometimes no longer appear to work
> (data is not received in a timely fashion for example). I would think
> this is just do to how complex the read/write logic is for openssl,
> nonblocking multi-threaded applications.

The most common non-obvious cause of this problem is failure to retry an
operation even though something changed after the last time you tried it. It
is important to retry all operations any time you make any forward progress,
not just the operation you think you made forward progress on.

For example, here's a common way you can deadlock:

Assume that your side is supposed to send next and the other side won't send
any data until you do. The other side has just sent some negotiation data
but you haven't received it yet. You can't send any data until you get it.
Now imagine this happens:

1) You call SSL_write, you get a 'WANT_READ' indication because the
negotiation data has not arrived yet.

2) The negotiation data arrives on the socket.

3) You call SSL_read and it returns 'WANT_READ' because the negotiation data
gave it no application data. It has now read the negotiation data.

4) You select for readability on the socket because both SSL_write and
SSL_read failed. You do not call SSL_read or SSL_write again until select
tells you to.

You are now deadlocked. You will not retry SSL_write until you read some
data. But the data you are waiting for has already arrived and been read (in
the call to SSL_read).

You must think very carefully about what the return values mean and retry
all operations (read and write) any time there's any chance that forward
progress has been made.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Multi-threaded SSL Socket Usage

[Andrew Armstrong]

In addition to the reply given below; I have a few follow-up questions after
reading some threads from mail-archive.com

Specifically;
http://www.mail-archive.com/openssl-users@openssl.org/msg46239.html

What's going on here?

If I receive WANT_READ, during an SSL_write - what does it want me to
actually do?

Does it want me to perform SSL_read? Or just 'select' the socket and wait
until it becomes readable; at which point, I then just write again?

Can someone please make it painfully clear on what exactly is expected of
the application when receiving these events.

Thanks,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Armstrong
Sent: Thursday, 17 May 2007 8:13 PM
To: openssl-users@openssl.org
Subject: FW: Multi-threaded SSL Socket Usage

Resend; it's been a few hours and my reply below has yet to come through.

- Andrew

-Original Message-
From: Andrew Armstrong [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 17 May 2007 6:49 PM
To: 'openssl-users@openssl.org'
Subject: RE: Multi-threaded SSL Socket Usage

Thanks for your response David, Rodney.

I understand (clearer now) the requirement that:

* If SSL_read reports WANT_WRITE; we need to issue an immediate SSL_write
However; what do I actually write? Do I write a blank/empty string
(SSL_write(ssl, "", 0)?) - I may not have anything to write. Please confirm?

* If SSL_read reports WANT_READ; re-try the read, before issuing an
SSL_write before the retry of the read. Please confirm?

* If SSL_write reports WANT_WRITE; re-try the write immediately, without
issuing an SSL_read before the retry of the write. Please confirm? 

* If SSL_write reports WANT_READ; issue an SSL_read on the socket before
issuing an SSL_write. Once the READ has been done, re-do the SSL_write.
Please confirm?

Additionally; the logic to selecting sockets for reading should be:

* If the readfd of the socket is set (via select())
OR
* The socket has reported WANT_READ from an operation

Can you please provide your thoughts on the above logic?

Many thanks for the help so far.

Regards,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Wednesday, 16 May 2007 3:19 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> The design of the application is that there are worker threads which
> pick up data and send them out via the sockets. This works for the most
> part, however as mentioned it will sometimes no longer appear to work
> (data is not received in a timely fashion for example). I would think
> this is just do to how complex the read/write logic is for openssl,
> nonblocking multi-threaded applications.

The most common non-obvious cause of this problem is failure to retry an
operation even though something changed after the last time you tried it. It
is important to retry all operations any time you make any forward progress,
not just the operation you think you made forward progress on.

For example, here's a common way you can deadlock:

Assume that your side is supposed to send next and the other side won't send
any data until you do. The other side has just sent some negotiation data
but you haven't received it yet. You can't send any data until you get it.
Now imagine this happens:

1) You call SSL_write, you get a 'WANT_READ' indication because the
negotiation data has not arrived yet.

2) The negotiation data arrives on the socket.

3) You call SSL_read and it returns 'WANT_READ' because the negotiation data
gave it no application data. It has now read the negotiation data.

4) You select for readability on the socket because both SSL_write and
SSL_read failed. You do not call SSL_read or SSL_write again until select
tells you to.

You are now deadlocked. You will not retry SSL_write until you read some
data. But the data you are waiting for has already arrived and been read (in
the call to SSL_read).

You must think very carefully about what the return values mean and retry
all operations (read and write) any time there's any chance that forward
progress has been made.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

FW: Multi-threaded SSL Socket Usage

[Andrew Armstrong]

Resend; it's been a few hours and my reply below has yet to come through.

- Andrew

-Original Message-
From: Andrew Armstrong [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 17 May 2007 6:49 PM
To: 'openssl-users@openssl.org'
Subject: RE: Multi-threaded SSL Socket Usage

Thanks for your response David, Rodney.

I understand (clearer now) the requirement that:

* If SSL_read reports WANT_WRITE; we need to issue an immediate SSL_write
However; what do I actually write? Do I write a blank/empty string
(SSL_write(ssl, "", 0)?) - I may not have anything to write. Please confirm?

* If SSL_read reports WANT_READ; re-try the read, before issuing an
SSL_write before the retry of the read. Please confirm?

* If SSL_write reports WANT_WRITE; re-try the write immediately, without
issuing an SSL_read before the retry of the write. Please confirm? 

* If SSL_write reports WANT_READ; issue an SSL_read on the socket before
issuing an SSL_write. Once the READ has been done, re-do the SSL_write.
Please confirm?

Additionally; the logic to selecting sockets for reading should be:

* If the readfd of the socket is set (via select())
OR
* The socket has reported WANT_READ from an operation

Can you please provide your thoughts on the above logic?

Many thanks for the help so far.

Regards,
Andrew

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Wednesday, 16 May 2007 3:19 AM
To: openssl-users@openssl.org
Subject: RE: Multi-threaded SSL Socket Usage


> The design of the application is that there are worker threads which
> pick up data and send them out via the sockets. This works for the most
> part, however as mentioned it will sometimes no longer appear to work
> (data is not received in a timely fashion for example). I would think
> this is just do to how complex the read/write logic is for openssl,
> nonblocking multi-threaded applications.

The most common non-obvious cause of this problem is failure to retry an
operation even though something changed after the last time you tried it. It
is important to retry all operations any time you make any forward progress,
not just the operation you think you made forward progress on.

For example, here's a common way you can deadlock:

Assume that your side is supposed to send next and the other side won't send
any data until you do. The other side has just sent some negotiation data
but you haven't received it yet. You can't send any data until you get it.
Now imagine this happens:

1) You call SSL_write, you get a 'WANT_READ' indication because the
negotiation data has not arrived yet.

2) The negotiation data arrives on the socket.

3) You call SSL_read and it returns 'WANT_READ' because the negotiation data
gave it no application data. It has now read the negotiation data.

4) You select for readability on the socket because both SSL_write and
SSL_read failed. You do not call SSL_read or SSL_write again until select
tells you to.

You are now deadlocked. You will not retry SSL_write until you read some
data. But the data you are waiting for has already arrived and been read (in
the call to SSL_read).

You must think very carefully about what the return values mean and retry
all operations (read and write) any time there's any chance that forward
progress has been made.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: New version of OpenSSL not recognised by OS

[Jan Pechanec]

On Thu, 17 May 2007, Leslie Katz wrote:

>I re-ran Rootkit Hunter and it still complained about my having the old
>version. I ran "openssl version" and that gave me the old version
>number too.

system shipped OpenSSL in Fedore is probably in /usr/bin, /usr/lib 
etc. When installing from source code, default location is /usr/local/...

run 'which openssl'
run '/usr/local/bin/openssl version'

installing a newer version will not help you anyway since system 
commands dependent on OpenSSL will stay dependent on the version shipped 
with the system.

you cannot copy newer libs over old ones since 0.9.7 branch is not 
binary compatible with 0.9.8 one.

Jan.

-- 
Jan Pechanec
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

New version of OpenSSL not recognised by OS

[Leslie Katz]

I'm using Fedora Core 3.



I intermittently run a program called Rootkit Hunter and, each time I
do, it complains that I'm using an old version of OpenSSL (v 0.9.7a).



That's the latest version of OpenSSL available in RPM form for Fedora Core 3.



Today, I decided to try to update my OpenSSL, so I downloaded a tar.gz
file of the latest version (0.9.8e) and tried to install it.



When I got to the "make install" stage, I got a lot of "permission
denied" messages, so I re-ran the "make install" as root. All seemed to
work then.



I re-ran Rootkit Hunter and it still complained about my having the old
version. I ran "openssl version" and that gave me the old version
number too.



To put it briefly, I'm in over my head here. I have no idea how to proceed.



I'd be grateful if some kind soul would tell me what I should be doing now to 
get the version recognised.



Thanks for reading this,



Leslie 

Visit http://stumblng.tumblr.com
An Australian lawyer's tumblelog about things (some legal, most not) you might 
otherwise have missed




  
___
How would you spend $50,000 to create a more sustainable environment in 
Australia?  Go to Yahoo!7 Answers and share your idea.
http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]