RE: Signature verification fails with block type is not 01

2007-10-15 Thread Belliappa, Ashith Muddiana (HP Software)
 
Hi,
We have checked for proper library files usage during the signature
verification. Even we have compared the file size of the library used in
working and non- working machine and found both are exactly same. Even
the checksum matches for the files.

In Solaris 5.7 also it works fine. The problem is in only one Solaris
5.8 box. 

1) What all shared system library files we need to check which could be
the possible reason for getting this error?
2) What are the machine configuration we need to check if that would
cause the failure?
3) Is there any specific OS patch that could create an problem? If yes,
please let me know.

Thanks in advance,
Regards
Ashith
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jimmy bahuleyan
Sent: Friday, October 12, 2007 5:46 PM
To: openssl-users@openssl.org
Subject: Re: Signature verification fails with block type is not 01

Belliappa, Ashith Muddiana (HP Software) wrote:
  
 Hi,
  We have complied the code in an Solaris 5.7 machine. We have the same

 set of binaries working fine in all the Solaris 5.8 machines. I am 
 getting the error ONLY in ONE Solaris 5.8 machine.
 

i believe your saying that the same application code, same set of
openssl libraries AND the same signature works on all but one Solaris
5.8.

Have you checked that the proper library is picked up on this machine
(or if shared libs are used, the proper library is loaded). Could
possibly be a machine config issue if all the above hold true..

(I haven't got 5.7 thing. Is it that you have also checked the code on a
5.7  found it to be working properly?)

 Does anyone have a separate test program where we can test only the 
 signature verification?
 
 Regards
 Ashith
 

-jb
--
No snowflake in an avalanche ever feels responsible.
__
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: When is the next release of openssl?

2007-10-15 Thread Prathima Dandapani -X (pdandapa - HCL at Cisco)
Hi,
 
 Any idea on the next release of openssl version in 0.9.7 series?
 
Thanks,
Prathima.


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prathima Dandapani -X
(pdandapa - HCL at Cisco)
Sent: Saturday, October 06, 2007 11:42 AM
To: openssl-users@openssl.org
Subject: When is the next release of openssl?


Any idea on the next release of openssl version
 
Thanks,
Prathima.


Re: Signature verification fails with block type is not 01

2007-10-15 Thread jimmy bahuleyan
Belliappa, Ashith Muddiana (HP Software) wrote:
  
 Hi,
 We have checked for proper library files usage during the signature
 verification. Even we have compared the file size of the library used in
 working and non- working machine and found both are exactly same. Even
 the checksum matches for the files.
 
 In Solaris 5.7 also it works fine. The problem is in only one Solaris
 5.8 box. 

i'm assuming the scenario is:

 build libs, application on 5.7, test it = works fine.
 build libs, application on 5.8, test it = works fine except one machine.
 signature, key is same in all cases.

 
 1) What all shared system library files we need to check which could be
 the possible reason for getting this error?
 2) What are the machine configuration we need to check if that would
 cause the failure?

what I meant was, if your building the application on one particular 5.8
machine and then using it to run on other 5.8s, it could /possibly/
happen that one of the test machines may not have the proper library at
the path that you're expecting. If you've already checked all of these,
then it shouldn't be a problem.

 3) Is there any specific OS patch that could create an problem? If yes,
 please let me know.

Well, wrt to OS patches I assume you're keeping all your machines at the
same patch level whatever it maybe.

 
 Thanks in advance,
 Regards
 Ashith
  

If all of these lead you no where, I'm out of clues. You could probably
try debug with the hints provided by Marek earlier.

-jb
-- 
No snowflake in an avalanche ever feels responsible.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Same SSL_CTX for tls client and tls server

2007-10-15 Thread Manish Jain
Hi,

My application will act as tls server and tls client. Whether I can use
same
SSL_CTX object for both client and server.

Whether 
1) it is thread safe?
2) how to configure different verify_callback for client and server
3) any known issues in using same SSL_CTX for tls client and server

Another query (different context)
When acting as a tls server, I have chain of certificates which should
be sent to clients connecting to my server. Additionally, I also have
build a chain to verify client certificates. How I can build these two
different chains on single SSL_CTX object?

Best Regards,
Manish Jain
GlobalLogic Inc.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Segmentation fault in application creating too many threads.

2007-10-15 Thread Prabhu S
Hi,

The SSL enabled client application seg faults when too many threads are
created. Each thread is a SSL client attempting a connection with Server.
The application sets  the static call back functions.:


static void locking_function(int mode, int n, const char * file, int line)
static unsigned long id_function(void)

The application creates about  800 threads in a Linux 2.6 Kernel.


#0  SHA1_Init (c=0x0) at sha_locl.h:150
#1  0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
#2  0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620,
impl=0x0) at digest.c:207
#3  0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add=
2.5863007356866632e-306) at md_rand.c:263
#4  0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0) at
rand_lib.c:151
#5  0x08a269f8 in ?? ()
#6  0x08a269f8 in ?? ()
#7  0x in ?? ()

When less number of threads are created I don't see the issue.

How do we use CRYPTO_set_idptr_callback()? OpenSSL document reads -  There
is still the issue of platforms where pthread_self() returns something other
than an integer. It is for cases like this that
CRYPTO_set_idptr_callback() comes
in handy

Regards,
Prabhu. S


Re: Segmentation fault in application creating too many threads.

2007-10-15 Thread Gayathri S

Hi Prabhu,

Can you check the sha1 usage count in the lsmod?
I am thinking you have not freed the sha tfm and eventually run out of it.
I hit a similar issue when making use of linux sha1.

Thanks
--Gayathri

On Mon, 15 Oct 2007, Prabhu S wrote:


Hi,

The SSL enabled client application seg faults when too many threads are
created. Each thread is a SSL client attempting a connection with Server.
The application sets  the static call back functions.:


static void locking_function(int mode, int n, const char * file, int line)
static unsigned long id_function(void)

The application creates about  800 threads in a Linux 2.6 Kernel.


#0  SHA1_Init (c=0x0) at sha_locl.h:150
#1  0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
#2  0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620,
impl=0x0) at digest.c:207
#3  0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add=
2.5863007356866632e-306) at md_rand.c:263
#4  0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0) at
rand_lib.c:151
#5  0x08a269f8 in ?? ()
#6  0x08a269f8 in ?? ()
#7  0x in ?? ()

When less number of threads are created I don't see the issue.

How do we use CRYPTO_set_idptr_callback()? OpenSSL document reads -  There
is still the issue of platforms where pthread_self() returns something other
than an integer. It is for cases like this that
CRYPTO_set_idptr_callback() comes
in handy

Regards,
Prabhu. S




This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.


Intoto Inc. 


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


RE: Segmentation fault in application creating too many threads.

2007-10-15 Thread David Schwartz

 The application creates about  800 threads in a Linux 2.6 Kernel.

This is really one of those don't do that then things.
Thread-per-connection is well-known to break down at about 750 connections.

 #0  SHA1_Init (c=0x0) at sha_locl.h:150
 #1  0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
 #2  0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230,
 type=0x4061f620, impl=0x0) at digest.c:207
 #3  0x405ac08e in ssleay_rand_add (buf=0x0, num=0,
 add= 2.5863007356866632e-306) at md_rand.c:263
 #4  0x405ace6e in RAND_add (buf=0x8a269f8,
 num=144861688, entropy=0) at rand_lib.c:151

It looks like OpenSSL doesn't properly check for an out-of-memory condition
in this code path. However, the main problem is that you ran out of virtual
memory.

It may help to reduce the stack size for each thread. But you really should
re-architect. Thread-per-connection is a brain dead approach for any server
that has to handle hundreds of connections.

DS


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