SSL_connect and SSL_accept deadlock!

[Md Lazreg]

I have an SSL client that connects to an SSL server. The server is able to
process 1000s of clients just fine on a variety of platforms
[Window/Linux/HP/Solairs] for long periods of time.

The problem that is driving me nuts is that from time to time like once
every 24 hours some client fails to connect to the server at the handshaking
phase. This happens only on Linux and HP. Other platforms do not experience
this issue.

Here is a sketch of my client and server code. Please note that I am using non
blocking sockets:

common code:
-
int ssl_retry(int ret)
{
   int r;
   fd_set fds;
   struct timeval tv, *ptv=0;
   tv.tv_sec =  1;/*do a select for 1 second each time*/
   tv.tv_usec = 0;
   ptv=&tv;
   FD_ZERO(&fds);

   switch(SSL_get_error(m_ssl, ret)
   {
case SSL_ERROR_NONE:
 r = 1;
 break;
case SSL_ERROR_WANT_READ:
FD_SET(m_sock_fd, &fds);
r=select(m_sock_fd + 1, &fds, 0, 0, ptv);
if (r <= 0 && (Errno == EAGAIN || Errno == EINTR))/*if we timed out
with EAGAIN try again*/
{
r = 1;
}
break;
case SSL_ERROR_WANT_WRITE:/
FD_SET(m_sock_fd, &fds);
r=select(m_sock_fd + 1, 0, &fds, 0, ptv);
if (r <= 0 && (Errno == EAGAIN || Errno == EINTR))/*if we timed out
with EAGAIN try again*/
{
r = 1;
}
break;
case SSL_ERROR_ZERO_RETURN:/*The socket closed*/
r = 0;
break;
case SSL_ERROR_SYSCALL:
case SSL_ERROR_SSL:
 r = -1;
 break;
default:
r = -1;
}
return r;

client code:
-
int time0 = time(NULL);
timeout=10 seconds;
while (t 0)
  {
 break;
  }
  r = ssl_retry(r);
  if ( r <= 0)
  {
 break;
  }
  t = time(NULL) - time0;
}
if (t>=timeout)
{
  I timed out:(
}
if (r>0)
{
  We are connected. Do work.
}
else
{
  Some kind of an issue.
}

server code:
-
int time0 = time(NULL);
timeout=10 seconds;
while (t 0)
  {
 break;
  }
  r = ssl_retry(r);
  if ( r <= 0)
  {
 break;
  }
  t = time(NULL) - time0;
}
if (t>=timeout)
{
  I timed out:(
}
if (r>0)
{
  We are connected. Do work.
}
else
{
  Some kind of an issue.
}


When this problem happens both the client and the server end up in the red
line above "I timed out"

With some debugging efforts I see that when this problem hits, both the
client and the server go repeatedly into the green section above, each one
of them seems to want to perform a read as the returned code
is SSL_ERROR_WANT_READ from both the SSL_connect and the SSL_accept calls.

This looks to me as a deadlock situation where both my server and my client
are wanting to do a READ until both of them timeout!

Can someone please suggest to me what is wrong with the above code and how
is this deadlock possible?? I am using openssl-1.0.0a

Re: trust settings on the root CA

[Dr. Stephen Henson]

On Tue, Nov 02, 2010, Michael Strder wrote:

> Michael Ströder wrote:
> > man 1ssl verify says:
> > 
> > "The third operation is to check the trust settings on the root CA. The root
> > CA should be trusted for the supplied purpose. For compatibility with 
> > previous
> > versions of SSLeay and OpenSSL a certificate with no trust settings is
> > considered to be valid for all purposes."
> > 
> > I wonder how certain trust settings can be set. How is it done?
> 
> Hmm, found some comments in the "trusted" root CA certs shipped with my Linux
> distribution.
> 
> There are lines containing for example
> 
> # alias=Entrust Root Certification Authority
> # trust=server-auth
> # openssl-trust=serverAuth
> 
> Is this how trust meta data is added to certs? Is that documented anywhere?
> 

It is added with the 'x509' utility. 

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: trust settings on the root CA

[Michael Ströder]

Michael Ströder wrote:
> man 1ssl verify says:
> 
> "The third operation is to check the trust settings on the root CA. The root
> CA should be trusted for the supplied purpose. For compatibility with previous
> versions of SSLeay and OpenSSL a certificate with no trust settings is
> considered to be valid for all purposes."
> 
> I wonder how certain trust settings can be set. How is it done?

Hmm, found some comments in the "trusted" root CA certs shipped with my Linux
distribution.

There are lines containing for example

# alias=Entrust Root Certification Authority
# trust=server-auth
# openssl-trust=serverAuth

Is this how trust meta data is added to certs? Is that documented anywhere?

Ciao, Michael.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

trust settings on the root CA

[Michael Ströder]

man 1ssl verify says:

"The third operation is to check the trust settings on the root CA. The root
CA should be trusted for the supplied purpose. For compatibility with previous
versions of SSLeay and OpenSSL a certificate with no trust settings is
considered to be valid for all purposes."

I wonder how certain trust settings can be set. How is it done?

Thanks for advance.

Ciao, Michael.


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

RE: B64_read_PKCS7 : Anyone modified the base64 reader to be more forgiving?

[Harakiri]

--- On Thu, 10/28/10, Dave Thompson  wrote:

> From: Dave Thompson 
> Subject: RE: B64_read_PKCS7 : Anyone modified the base64 reader to be more 
> forgiving?
> To: openssl-users@openssl.org
> Date: Thursday, October 28, 2010, 7:00 PM
> > From: owner-openssl-us...@openssl.org
> On Behalf Of Harakiri
> > Sent: Thursday, 28 October, 2010 07:52
> 

> > 
> BIO_set_flags(b64,BIO_FLAGS_BASE64_NO_NL)
> 
> Output doesn't generate (any) linebreaks. Input doesn't 
> REQUIRE them every <80, but does ALLOW them anywhere.

i tried this - however it does not work - i patched the method in question

static PKCS7 *B64_read_PKCS7(BIO *bio)
{
  BIO *b64;
  PKCS7 *p7;
  if(!(b64 = BIO_new(BIO_f_base64( {
PKCS7err(PKCS7_F_B64_READ_PKCS7,ERR_R_MALLOC_FAILURE);
return 0;
  }
  printf("Testing..");
  BIO_set_flags(b64,BIO_FLAGS_BASE64_NO_NL);
  bio = BIO_push(b64, bio);
  if(!(p7 = d2i_PKCS7_bio(bio, NULL)))
PKCS7err(PKCS7_F_B64_READ_PKCS7,PKCS7_R_DECODE_ERROR);
  BIO_flush(bio);
  bio = BIO_pop(bio);
  BIO_free(b64);
  return p7;
}

I used a simple smime signed message where the last base64 line was faulty:

DhBgOxHXEhy/CzkNjQysNxJQ492WCybahjBwpRfJRU3i0qwW1SBG+7XL4lEZ2CfaOdheE2yM3Ooo


the last 4 A should be in the next line

However, now another error is returned (header too long)

24073:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too 
long:asn1_lib.c:150:
24073:error:21078082:PKCS7 routines:B64_READ_PKCS7:decode error:pk7_mime.c:142:
24073:error:2107A08C:PKCS7 routines:SMIME_read_PKCS7:pkcs7 sig parse 
error:pk7_mime.c:349:

previously it was the not enough data error

24091:error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough 
data:a_d2i_fp.c:238:
24091:error:21078082:PKCS7 routines:B64_READ_PKCS7:decode error:pk7_mime.c:140:
24091:error:2107A08C:PKCS7 routines:SMIME_read_PKCS7:pkcs7 sig parse 
error:pk7_mime.c:347:

Any ideas ?

Putting the 4 A in the last line fixed it so the base64 itself is technically 
OK.

Thanks


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

cross compile openSSL for octeom

[Naama Bar Menachem]

Hi

 

I need to cross-compile openSSL.

My target should be:  mips64-octeon-linux-gnu

And the host is:i686-pc-linux-gnu

How can I do so? I don't find "octeon" on the os/compiler list
./Configure is showing

 

Naaama Bar-Menachem

Software Engineer, R&D

 

T: +972-9788-9737 | M: +972-57-641-1810 | F: +972-9-958-9731  | 
naama.barmenac...@novelsat.com   

Novelsat Ltd. 21st Hataasiya St. Raanana 43654, Israel  | 
www.novelsat.com  

P Please consider the environment before printing this e-mail.

 

<>

String-Representations of DNs

[Michael Ströder]

HI!

It's confusing that OpenSSL seems to output distinguished names in different
string representations.

While one can use command-line argument -nameopt to influence the output of
openssl x509 -issuer -subject this does not affect DN output of X.509v3
extensions and there's no such argument for openssl verify.

Would it be much work to unify the string output of DNs?

Ciao, Michael.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: B64_read_PKCS7 : Anyone modified the base64 reader to be more forgiving?

[Harakiri]

--- On Thu, 10/28/10, Dave Thompson  wrote:

> From: Dave Thompson 
> Subject: RE: B64_read_PKCS7 : Anyone modified the base64 reader to be more 
> forgiving?
> To: openssl-users@openssl.org
> Date: Thursday, October 28, 2010, 7:00 PM
> > From: owner-openssl-us...@openssl.org
> On Behalf Of Harakiri
> > Sent: Thursday, 28 October, 2010 07:52

> > 
> > However, it would be easy to fix i guess - the base64
> reader 
> > simply must ignore the rule that each line has to be a
> certain length.
> > 
> BIO_set_flags(b64,BIO_FLAGS_BASE64_NO_NL)
> 
> Output doesn't generate (any) linebreaks. Input doesn't 
> REQUIRE them every <80, but does ALLOW them anywhere.

Thanks for your reply, that does look like a good idea - however you say that 
the output doesnt generate any newlines either - well this not wanted because 
after decryption/verification the output generated by the CMD would then 
contain an invalid encoded message if the base64 block is just one line with no 
new lines.

Is BIO_set_flags(b64,BIO_FLAGS_BASE64_NO_NL) a global variable? 

Maybe it would be possible to set this to ignore NL/errors for reading but 
reset it again for writing the resulting message ?


> Alternatively, instead of using a BIO directly on the
> message 
> as received, you could first correct it by just breaking
> any 
> overlong base64 line(s); instead of actually parsing MIME 
> maybe you can assume nonheader nonmarker is base64 body.
> If it fits in memory you can just read it in and fix it, 
> then point to that in a memBIO you give to SIME_read_.
> If not you probably have to make a BIO_pair and a thread 
> that feeds your end with corrected data while OpenSSL 
> consumes the other end.

That sounds pretty complicated actually, and i dont want to pipe it into 
memory, it should work for streaming (as the default) so it can handle very 
large messages too.

Thanks for your reply.

Regards


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