Re: [openssl-users] Integrating New Cipher Suite

[Schmicker, Robert]

Added a define in include/openssl/ssl.h:
   # define SSL_TXT_MYCIPHER   "MYCIPHER"

Integrated into ssl/s3_lib.c:
   static SSL_CIPHER ssl3_ciphers[] = {

   {
1,
TLS1_TXT_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
TLS1_CK_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
SSL_kECDHE,
SSL_aECDSA,
SSL_MYCIPHER,
SSL_AEAD,
TLS1_2_VERSION, TLS1_2_VERSION,
DTLS1_2_VERSION, DTLS1_2_VERSION,
SSL_HIGH | SSL_FIPS,
SSL_HANDSHAKE_MAC_SHA384 | TLS1_PRF_SHA384,
64,
64,
   },


>That's a pretty small number of bits. Do you really mean it to be only 64?
>
>Does you ciphersuite show up with cipher -s?
>
>It's possible it is being rejected because it has insufficient security. If
>the number of bits is really 64 you could try droppping the security level to
>0 to allow it.
>
>If that doesn't help enable trace support with enable-ssl-trace and then try
>the -trace command ot s_client/s_server and see if the new ciphersuites is
>sent in ClientHello
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org


After some debugging (exactly as mentioned above) it appears that the cipher 
suite does not show up in the ClientHello using the s_client/s_server. I 
modified the cipher for testing to use 512 bits instead of 64 so that it is 
ranked highest.

Error server side:
SSL routines:tls_post_process_client_hello:no shared 
cipher:ssl/statem/statem_srvr.c:1979

Error Client side:
SSL routines:ssl3_read_bytes:tlsv1 alert internal 
error:ssl/record/rec_layer_s3.c:1469:SSL alert number 80

Any idea why the cipher would appear under the list of supported tls1.2 
ciphers, yet it does not appear under the ClientHello even if specified with 
the -cipher option?

Thank you for any leads!
Rob


On 4/12/17 8:06 AM, 
openssl-users-requ...@openssl.org 
wrote:

Send openssl-users mailing list submissions to
openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to

openssl-users-requ...@openssl.org

You can reach the person managing the list at
openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Integrating New Cipher Suite (Dr. Stephen Henson)
   2. Re: RSA PKCS1 v2.1 - Multi-primes and RSASSA-PSS (Davy Souza)
   3.  Escaped Issuer/Subject (c.hol...@ades.at)
   4. Multithreading: Global locks causing bottleneck in parallel
  SSL_write calls (dipakgaigole)


--

Message: 1
Date: Tue, 11 Apr 2017 18:54:09 +
From: "Dr. Stephen Henson" 
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Integrating New Cipher Suite
Message-ID: 
<20170411185409.ga23...@openssl.org>
Content-Type: text/plain; charset=us-ascii

On Tue, Apr 11, 2017, Schmicker, Robert wrote:



Added a define in include/openssl/ssl.h:
   # define SSL_TXT_MYCIPHER   "MYCIPHER"

Integrated into ssl/s3_lib.c:
   static SSL_CIPHER ssl3_ciphers[] = {

   {
1,
TLS1_TXT_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
TLS1_CK_ECDHE_ECDSA_WITH_MYCIPHER_SHA384,
SSL_kECDHE,
SSL_aECDSA,
SSL_MYCIPHER,
SSL_AEAD,
TLS1_2_VERSION, TLS1_2_VERSION,
DTLS1_2_VERSION, DTLS1_2_VERSION,
SSL_HIGH | SSL_FIPS,
SSL_HANDSHAKE_MAC_SHA384 | TLS1_PRF_SHA384,
64,
64,
   },



That's a pretty small number of bits. Do you really mean it to be only 64?

Does you ciphersuite show up with cipher -s?

It's possible it is being rejected because it has insufficient security. If
the number of bits is really 64 you could try droppping the security level to
0 to allow it.

If that doesn't help enable trace support with enable-ssl-trace and then try
the -trace command ot s_client/s_server and see if the new ciphersuites is
sent in ClientHello

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


--

Message: 2
Date: Tue, 11 Apr 2017 12:50:29 +
From: Davy Souza 
To: "openssl-users@openssl.org" 

Subject: Re: [openssl-users] RSA PKCS1 v2.1 - Multi-primes and
RSASSA-PSS
Message-ID:

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

On 13/04/17 18:26, Martin Brejcha wrote:
> 
> 
> Matt Caswell wrote on 04/13/2017 03:45 PM:
>>
>>
>> On 13/04/17 10:11, mahesh gs wrote:
>>> Hi,
>>>
>>> We are running SCTP connections with DTLS enabled in our application. We
>>> have adapted openssl version (openssl-1.1.0e) to achieve the same.
>>>
>>> We have generated the self signed root and node certificates for
>>> testing. We have a strange problem with the incomplete DTLS handshake if
>>> we run the DTLS client and DTLS server is different systems.If we run
>>> the DTLS client and server in same system handshake is successful,
>>> handshake is not successful if run client and server in different VM's.
>>>
>>> This strange problem happens only for SCTP/DTLS connection. With the
>>> same set of certificates TCP/TLS connection is successful and we are
>>> able to exchange the application data.
>>>
>>> I am attaching the code bits for SSL_accept and SSL_connect and also the
>>> wireshark trace of unsuccessful handshake. Please assist me to debug
>>> this problem.
>>>
>>> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
>>> SSL_connect is called 4 or 5 times and select system call timeout.
>>
>> Your trace shows the following interactions occurring:
>>
>> Client Server
>> -- --
>>
>> ClientHello  >
>>  < ServerHello
>>  < Certificate
>>  < CertificateRequest
>>  < ServerDone
>> Certificate  ->
>> ClientKeyExchange->
>> CertificateVerify->
>> CCS  ->
>> [Encrypted Finished]
>>
>> We would expect the server to continue with its own CCS and Encrypted
>> Finished to complete the handshake. It seems that, for some reason, the
>> server is not receiving (or acting upon) the client's second flight of
>> messages.
>>
>> Normally in DTLS this sort of thing can happen due to lost messages etc
>> but, obviously, with SCTP, this is not the case. Something else must be
>> happening.
>>
> 
> There are some SCTP segmented messages during handshake.
> May be some issue in reassembling could lead to strange behavior.
> Can be observed these segmented messages also when the handshake is 
> successful?

That's an interesting question. The segmented messages are for the
Certificate messages. Obviously the client is able to read them just
fine (because it responds with its own Certificate message), but there
could plausibly be an issue on the server side. It would be interesting
to see what happens if you temporarily disable client auth so that the
client does not send this large Certficate message.

Matt



signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Dipak Gaigole
> Sent: Thursday, April 13, 2017 15:12

>  I will try with disabling FIPS.

Opinions differ, but many people - including myself - recommend not enabling 
FIPS mode unless it is explicitly required (generally because you work for the 
US Federal Government or a relatively small number of other organizations that 
let bureaucracy stand in the way of security).

> Where can i find current best practice cipher list? Or Can you suggest few?

The free ebook /OpenSSL Cookbook/ from Feisty Duck is a good place to start. It 
was updated only a year ago, so it's reasonably current.

https://www.feistyduck.com/books/openssl-cookbook/

Beyond that, you really need to be following current research, or at least the 
people who write knowledgeably about current research.

Ben wrote "AES256-SHA is both CBC and SHA1, neither of which is really a 
current best practice". Certainly the bloom is off the rose of SHA1, 
particularly since the "SHAttered" demonstration of a successful collision. The 
reality is that SHA1 is still fine for many purposes in practice; but if you're 
in a position to pick a better digest, it makes sense to do so. That means 
SHA-256 or SHA-384; or perhaps SHA3 with appropriate parameters, but SHA3 
hasn't seen widespread adoption yet. (That's more or less by design - NIST 
wanted to standardize SHA3 before it was needed.)

Regarding CBC, he presumably was referring to the various issues with CBC mode 
and the general move to various AE and AEAD combining modes, particularly GCM. 
AES-GCM suites are most people's default recommendation these days, when there 
aren't any compelling reasons to use something else. With GCM you have to be 
careful that you have a solid implementation and you never reuse an IV, so it's 
a bit easier for a non-expert to screw up. But considering the aforementioned 
issues with CBC, it's easy to see why people recommend it.

There's a ton of information - more than a non-expert can be expected to absorb 
- on these topics available online, even if we ignore the actual primary 
research and just look at treatments for lay readers. Adam Langley talks about 
the problems with AES-CBC in particular in this post, for example:

https://security.googleblog.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

In TLS, AES-CBC is vulnerable to the BEAST (TLS 1.0 only) and Lucky13 attacks, 
given certain other conditions. Lucky13 (aka "Lucky Thirteen") actually applies 
to all block ciphers in CBC mode, if the implementation exposes certain timing 
side channels. These days decent implementations (including OpenSSL) try to 
remove or whiten side channels, but that's actually quite difficult to do 
comprehensively (see various pieces of research published over the past several 
years). Again, for many applications, these attacks simply aren't feasible. But 
many applications are developed without the benefit of a cryptographer who can 
look at them and decide whether you need to worry about them.


Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls

[Dipak Gaigole]

 The OpenSSL PRNG story is currently not so great, yes. But maybe 
you should try without FIPS, and also with a different cipher? AES256-SHA 
is both CBC and SHA1, neither of which is really a current best practice. 
-BenThanks Ben. I will try with disabling FIPS. Where can i find current best 
practice cipher list? Or Can you suggest few?-DipakIf you reply to this 
email, your message will be added to the discussion 
below:http://openssl.6102.n7.nabble.com/Multithreading-Global-locks-causing-bottleneck-in-parallel-SSL-write-calls-tp70400p70407.html
To start a new topic under OpenSSL - User, email 
ml-node+s6102n3h16@n7.nabble.comTo unsubscribe from OpenSSL, click here.NAML



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Multithreading-Global-locks-causing-bottleneck-in-parallel-SSL-write-calls-tp70400p70426.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

> On 13. Apr 2017, at 19:26, Martin Brejcha  wrote:
> 
> 
> 
> Matt Caswell wrote on 04/13/2017 03:45 PM:
>> 
>> 
>> On 13/04/17 10:11, mahesh gs wrote:
>>> Hi,
>>> 
>>> We are running SCTP connections with DTLS enabled in our application. We
>>> have adapted openssl version (openssl-1.1.0e) to achieve the same.
>>> 
>>> We have generated the self signed root and node certificates for
>>> testing. We have a strange problem with the incomplete DTLS handshake if
>>> we run the DTLS client and DTLS server is different systems.If we run
>>> the DTLS client and server in same system handshake is successful,
>>> handshake is not successful if run client and server in different VM's.
>>> 
>>> This strange problem happens only for SCTP/DTLS connection. With the
>>> same set of certificates TCP/TLS connection is successful and we are
>>> able to exchange the application data.
>>> 
>>> I am attaching the code bits for SSL_accept and SSL_connect and also the
>>> wireshark trace of unsuccessful handshake. Please assist me to debug
>>> this problem.
>>> 
>>> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
>>> SSL_connect is called 4 or 5 times and select system call timeout.
>> 
>> Your trace shows the following interactions occurring:
>> 
>> Client Server
>> -- --
>> 
>> ClientHello  >
>> < ServerHello
>> < Certificate
>> < CertificateRequest
>> < ServerDone
>> Certificate  ->
>> ClientKeyExchange->
>> CertificateVerify->
>> CCS  ->
>> [Encrypted Finished]
>> 
>> We would expect the server to continue with its own CCS and Encrypted
>> Finished to complete the handshake. It seems that, for some reason, the
>> server is not receiving (or acting upon) the client's second flight of
>> messages.
>> 
>> Normally in DTLS this sort of thing can happen due to lost messages etc
>> but, obviously, with SCTP, this is not the case. Something else must be
>> happening.
>> 
> 
> There are some SCTP segmented messages during handshake.
> May be some issue in reassembling could lead to strange behavior.
> Can be observed these segmented messages also when the handshake is 
> successful?
Which OS are you using?

The OpenSSL code expects the kernel to reassemble the messages. Can you check
if this is true using truss on FreeBSD or a similar tool on Linux?

Best regards
Michael
> 
> M.
> 
> 
>> In your description you say SSL_accept() gets called repeatedly and
>> always gives SSL_ERROR_WANT_READ. Looking at your code it looks like you
>> are calling pollSocketForEvents() after each accept. I am assuming that
>> this is returning true each time (otherwise you would break out of the
>> loop). This suggests that the "select" call thinks there is something to
>> read from the underlying socket. Am I correct? The question is why
>> doesn't OpenSSL then read that data out of the socket?
>> 
>> Are you able to build a debug version of OpenSSL (run "config" with -d),
>> and step through to figure out where it gets stuck. Is it attempting to
>> read the data and failing, or does it not get as far attempting to read it?
>> 
>> Another question: does this fail every time or does it sometimes work
>> and sometimes not (which might suggest some race condition)?
>> 
>> Matt
>> 
> <0xB42AB632.asc>-- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

Matt Caswell wrote on 04/13/2017 03:45 PM:
> 
> 
> On 13/04/17 10:11, mahesh gs wrote:
>> Hi,
>>
>> We are running SCTP connections with DTLS enabled in our application. We
>> have adapted openssl version (openssl-1.1.0e) to achieve the same.
>>
>> We have generated the self signed root and node certificates for
>> testing. We have a strange problem with the incomplete DTLS handshake if
>> we run the DTLS client and DTLS server is different systems.If we run
>> the DTLS client and server in same system handshake is successful,
>> handshake is not successful if run client and server in different VM's.
>>
>> This strange problem happens only for SCTP/DTLS connection. With the
>> same set of certificates TCP/TLS connection is successful and we are
>> able to exchange the application data.
>>
>> I am attaching the code bits for SSL_accept and SSL_connect and also the
>> wireshark trace of unsuccessful handshake. Please assist me to debug
>> this problem.
>>
>> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
>> SSL_connect is called 4 or 5 times and select system call timeout.
> 
> Your trace shows the following interactions occurring:
> 
> Client Server
> -- --
> 
> ClientHello  >
>  < ServerHello
>  < Certificate
>  < CertificateRequest
>  < ServerDone
> Certificate  ->
> ClientKeyExchange->
> CertificateVerify->
> CCS  ->
> [Encrypted Finished]
> 
> We would expect the server to continue with its own CCS and Encrypted
> Finished to complete the handshake. It seems that, for some reason, the
> server is not receiving (or acting upon) the client's second flight of
> messages.
> 
> Normally in DTLS this sort of thing can happen due to lost messages etc
> but, obviously, with SCTP, this is not the case. Something else must be
> happening.
> 

There are some SCTP segmented messages during handshake.
May be some issue in reassembling could lead to strange behavior.
Can be observed these segmented messages also when the handshake is successful?

M.


> In your description you say SSL_accept() gets called repeatedly and
> always gives SSL_ERROR_WANT_READ. Looking at your code it looks like you
> are calling pollSocketForEvents() after each accept. I am assuming that
> this is returning true each time (otherwise you would break out of the
> loop). This suggests that the "select" call thinks there is something to
> read from the underlying socket. Am I correct? The question is why
> doesn't OpenSSL then read that data out of the socket?
> 
> Are you able to build a debug version of OpenSSL (run "config" with -d),
> and step through to figure out where it gets stuck. Is it attempting to
> read the data and failing, or does it not get as far attempting to read it?
> 
> Another question: does this fail every time or does it sometimes work
> and sometimes not (which might suggest some race condition)?
> 
> Matt
> 


0xB42AB632.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

> On 13. Apr 2017, at 11:11, mahesh gs  wrote:
> 
> Hi,
> 
> We are running SCTP connections with DTLS enabled in our application. We have 
> adapted openssl version (openssl-1.1.0e) to achieve the same.
> 
> We have generated the self signed root and node certificates for testing. We 
> have a strange problem with the incomplete DTLS handshake if we run the DTLS 
> client and DTLS server is different systems.If we run the DTLS client and 
> server in same system handshake is successful, handshake is not successful if 
> run client and server in different VM's.
> 
> This strange problem happens only for SCTP/DTLS connection. With the same set 
> of certificates TCP/TLS connection is successful and we are able to exchange 
> the application data.
> 
> I am attaching the code bits for SSL_accept and SSL_connect and also the 
> wireshark trace of unsuccessful handshake. Please assist me to debug this 
> problem.
> 
> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but SSL_connect is 
> called 4 or 5 times and select system call timeout.
We are currently implementing DTLS/SCTP support in a project and seem to 
experience a similar
problem. Haven't hunted it down...

Are you using blocking or unblocking I/O?

Best regards
Michael
> 
> Thanks,
> Mahesh G S
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

On 13/04/17 10:11, mahesh gs wrote:
> Hi,
> 
> We are running SCTP connections with DTLS enabled in our application. We
> have adapted openssl version (openssl-1.1.0e) to achieve the same.
> 
> We have generated the self signed root and node certificates for
> testing. We have a strange problem with the incomplete DTLS handshake if
> we run the DTLS client and DTLS server is different systems.If we run
> the DTLS client and server in same system handshake is successful,
> handshake is not successful if run client and server in different VM's.
> 
> This strange problem happens only for SCTP/DTLS connection. With the
> same set of certificates TCP/TLS connection is successful and we are
> able to exchange the application data.
> 
> I am attaching the code bits for SSL_accept and SSL_connect and also the
> wireshark trace of unsuccessful handshake. Please assist me to debug
> this problem.
> 
> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
> SSL_connect is called 4 or 5 times and select system call timeout.

Your trace shows the following interactions occurring:

Client Server
-- --

ClientHello  >
 < ServerHello
 < Certificate
 < CertificateRequest
 < ServerDone
Certificate  ->
ClientKeyExchange->
CertificateVerify->
CCS  ->
[Encrypted Finished]

We would expect the server to continue with its own CCS and Encrypted
Finished to complete the handshake. It seems that, for some reason, the
server is not receiving (or acting upon) the client's second flight of
messages.

Normally in DTLS this sort of thing can happen due to lost messages etc
but, obviously, with SCTP, this is not the case. Something else must be
happening.

In your description you say SSL_accept() gets called repeatedly and
always gives SSL_ERROR_WANT_READ. Looking at your code it looks like you
are calling pollSocketForEvents() after each accept. I am assuming that
this is returning true each time (otherwise you would break out of the
loop). This suggests that the "select" call thinks there is something to
read from the underlying socket. Am I correct? The question is why
doesn't OpenSSL then read that data out of the socket?

Are you able to build a debug version of OpenSSL (run "config" with -d),
and step through to figure out where it gets stuck. Is it attempting to
read the data and failing, or does it not get as far attempting to read it?

Another question: does this fail every time or does it sometimes work
and sometimes not (which might suggest some race condition)?

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Query regarding DTLS handshake

[mahesh gs]

Hi,

We are running SCTP connections with DTLS enabled in our application. We
have adapted openssl version (openssl-1.1.0e) to achieve the same.

We have generated the self signed root and node certificates for testing.
We have a strange problem with the incomplete DTLS handshake if we run the
DTLS client and DTLS server is different systems.If we run the DTLS client
and server in same system handshake is successful, handshake is not
successful if run client and server in different VM's.

This strange problem happens only for SCTP/DTLS connection. With the same
set of certificates TCP/TLS connection is successful and we are able to
exchange the application data.

I am attaching the code bits for SSL_accept and SSL_connect and also the
wireshark trace of unsuccessful handshake. Please assist me to debug this
problem.

SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but SSL_connect
is called 4 or 5 times and select system call timeout.

Thanks,
Mahesh G S

bool pollSocketForEvents(long aTlsError)
{
  /* This function is to implement the SSL Socket call behaviour
  http://jmarshall.com/stuff/handling-nbio-errors-in-openssl.html */
  
  fd_set readFds, writeFds;
  struct timeval timeout;
  int retValue;
  
  int nfds = getSocketId();
  
  FD_SET(nfds, );
  FD_SET(nfds, );

  /* Wait for 5 Seconds */
  timeout.tv_usec = 0;
  timeout.tv_sec = 5;

  if (SSL_ERROR_WANT_READ == aTlsError)
  {
retValue = select(nfds + 1, , NULL, NULL, );
if (retValue <= 0)
{
  // Timeout or error just return failure
  return false;
}
  }

  if (SSL_ERROR_WANT_WRITE == aTlsError)
  {
retValue = select(nfds + 1, NULL, , NULL, );
if (retValue <= 0)
{ 
  // Timeout or error just return failure
  return false;
}
  }

  return true;
}   


void acceptTlsConnection()
{   
TRACE_CALL_BEGIN_MGR (ivManager);

long aTlsError;
bool retry = true;
const char *aFile;
int aLine;
long aRetValue;
  
/* Create an SSL Session for server */
if (createSSLSession(false))
{
  /* Throw failure exception */
  TRACE_CALL_END_MGR (ivManager);
  throw (TLSException(TLSException::eSSLContextCreationFailure, " Error 
while creating context for accepted connection"));
}

do
{
  /* Clear SSL error queue */
  ERR_clear_error();

  /* Initiate SSL Handshake */
  aRetValue = SSL_accept(ivSSL);

  if (aRetValue <= 0)
  {
aTlsError = SSL_get_error(ivSSL, aRetValue);  

switch(aTlsError)
{
  case SSL_ERROR_WANT_READ:
  case SSL_ERROR_WANT_WRITE:
  {
  /* Select on the socket for read/write events */
  retry = pollSocketForEvents(aTlsError);

  /* Nothing to do retry for accepting new connection */
  INSD_LOG(ivManager, INSD_LOG_INFO," SSL_accept() fails to 
accept new connection "
  "need to retry, returned error code %d ", aTlsError);
  }
  break;

  case SSL_ERROR_SYSCALL:

  if (EWOULDBLOCK == errno || EAGAIN == errno)
  {
/* Nothing to do retry for accepting new connection */
INSD_LOG(ivManager, INSD_LOG_INFO," SSL_accept() fails to 
accept new connection "
"need to retry, returned error code %d ", aTlsError);
  }
  else
  {
int aRet = ERR_get_error_line(, );

INSD_LOG(ivManager, INSD_LOG_ERROR," SSL File : %s , Line 
number : %d , "
  "Socket Id %d, Linux Error Code %d", aFile, aLine, 
getSocketId(), errno);

INSD_LOG(ivManager, INSD_LOG_ERROR,"SSL_accept () :: Result 
Code : %d ", aTlsError);

retry = false;
  }

  break;

  default:
  {
int aRet = ERR_get_error_line(, );

INSD_LOG(ivManager, INSD_LOG_ERROR,"(SSL_accept) Failed to 
accept new connection, "
  " Socket Id %d, Return Value %d ", getSocketId(), aTlsError);

INSD_LOG(ivManager, INSD_LOG_ERROR," SSL File : %s , Line 
number : %d , Linux Error Code %d", aFile, aLine, errno);


retry = false;
  }
  
  break;
  }
}
  }while (aRetValue != 1 && retry != false);

  if (aRetValue <= 0)
  {
/* Throw failure exception */
TRACE_CALL_END_MGR (ivManager);
throw