Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi Matt,

I have raised bug.

https://github.com/openssl/openssl/issues/4763

Thanks,
Mahesh G S

On Tue, Nov 21, 2017 at 3:26 PM, Matt Caswell <m...@openssl.org> wrote:

> Sounds like a bug. Can you raise this as an issue on github?
>
> https://github.com/openssl/openssl/issues
>
> Thanks
>
> Matt
>
>
> On 21/11/17 08:53, mahesh gs wrote:
> > Hi,
> >
> > We were able to further localize this problem and found the problem is
> > with the function "BIO_dgram_sctp_wait_for_dry". In this function after
> > enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to
> > peek to the message at SCTP layer, in this case the size of the message
> > waiting in the lower layer is 15 which size is exactly the size of
> > "Handshake Alert" that is received from the server and waiting to be
> > read. Dry event is never read from the lower layer that causes the
> > SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application.
> >
> > Current version of openssl we are using is 01.01.00g.
> >
> > We have tested and able to reproduce this issue with the OPENSSL
> > 01.00.02k version that is packaged with RHEL 7.4 as well.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <mahesh...@gmail.com
> > <mailto:mahesh...@gmail.com>> wrote:
> >
> > Hi Matt,
> >
> > Thanks for the response.
> >
> > We debugged through openssl code to get to know the reason why
> > client is not reading "SSL Alert".
> >
> > Once the "ClientKeyExchange" is sent openssl trying to send out the
> > "ChangeCipherSpec"  message which is creating the problem.
> >
> > The pre-work function for "ChangeCipherSpec" enables SCTP dry event
> > and wait for dry event notification.
> >
> > Inline image 1
> >
> >
> > In this scenario, dry notification is never sent from SCTP.
> > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow
> > never enters "read_state_machine" where alert is to be red.This
> > causes SSL_Connect to be in infinite loop.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org
> > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 17/11/17 06:42, mahesh gs wrote:
> > >  Why
> > > does client respond with "Client key exchange" even if the the
> handshake
> > > failure alert is sent from server?
> >
> > The client will send its entire flight of messages before it
> > attempts to
> > read anything from the server. So, in this case, the
> > ClientKeyExchange
> > message is still sent because the client hasn't read the alert
> yet.
> >
> > Matt
> >
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> > <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> >
> --
> 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] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi,

We were able to further localize this problem and found the problem is with
the function "BIO_dgram_sctp_wait_for_dry". In this function after enabling
the "sctp_sender_dry_event" we are trying to do MSG_PEEK to peek to the
message at SCTP layer, in this case the size of the message waiting in the
lower layer is 15 which size is exactly the size of "Handshake Alert" that
is received from the server and waiting to be read. Dry event is never read
from the lower layer that causes the SUB_STATE_ERROR and intern causes the
SSL_Connect to loop in application.

Current version of openssl we are using is 01.01.00g.

We have tested and able to reproduce this issue with the OPENSSL 01.00.02k
version that is packaged with RHEL 7.4 as well.


Thanks,
Mahesh G S

On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <mahesh...@gmail.com> wrote:

> Hi Matt,
>
> Thanks for the response.
>
> We debugged through openssl code to get to know the reason why client is
> not reading "SSL Alert".
>
> Once the "ClientKeyExchange" is sent openssl trying to send out the
> "ChangeCipherSpec"  message which is creating the problem.
>
> The pre-work function for "ChangeCipherSpec" enables SCTP dry event and
> wait for dry event notification.
>
> [image: Inline image 1]
>
>
> In this scenario, dry notification is never sent from SCTP.
> "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never
> enters "read_state_machine" where alert is to be red.This causes
> SSL_Connect to be in infinite loop.
>
>
> Thanks,
> Mahesh G S
>
> On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org> wrote:
>
>>
>>
>> On 17/11/17 06:42, mahesh gs wrote:
>> >  Why
>> > does client respond with "Client key exchange" even if the the handshake
>> > failure alert is sent from server?
>>
>> The client will send its entire flight of messages before it attempts to
>> read anything from the server. So, in this case, the ClientKeyExchange
>> message is still sent because the client hasn't read the alert yet.
>>
>> Matt
>>
>> --
>> 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] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi Matt,

Thanks for the response.

We debugged through openssl code to get to know the reason why client is
not reading "SSL Alert".

Once the "ClientKeyExchange" is sent openssl trying to send out the
"ChangeCipherSpec"  message which is creating the problem.

The pre-work function for "ChangeCipherSpec" enables SCTP dry event and
wait for dry event notification.

[image: Inline image 1]


In this scenario, dry notification is never sent from SCTP.
"dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never
enters "read_state_machine" where alert is to be red.This causes
SSL_Connect to be in infinite loop.


Thanks,
Mahesh G S

On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 17/11/17 06:42, mahesh gs wrote:
> >  Why
> > does client respond with "Client key exchange" even if the the handshake
> > failure alert is sent from server?
>
> The client will send its entire flight of messages before it attempts to
> read anything from the server. So, in this case, the ClientKeyExchange
> message is still sent because the client hasn't read the alert yet.
>
> Matt
>
> --
> 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] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi Matt,

Thanks for the response,

I added a log as suggested by you. I don't see the call entering the above
mentioned code block.

Logs on server side:

[10/15/0117 10:34:43] 803F1700 Link-2 (SSL_accept) Failed to accept
new connection,  Socket Id 65, Return Value 1
[10/15/0117 10:34:43] 803F1700 Link-2 SSL File :
ssl/statem/statem_srvr.c , Line number : 2882 , Linux Error Code 0

Logs on client side:

[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true


We observe from wireshark capture, client sending out the certificate with
length = 0 (because we have not configured the public key on client side)
and also server sends handshake failure "Alert" to client. Why does client
respond with "Client key exchange" even if the the handshake failure alert
is sent from server?

Openssl version used is 01.01.00g. I am also attaching the latest pcap file
for your reference.


On Tue, Nov 14, 2017 at 4:35 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 14/11/17 10:44, mahesh gs wrote:
>
> > case SSL_ERROR_SYSCALL:
> >
> > if (EWOULDBLOCK == errno || EAGAIN == errno)
> > {
> >   /* Nothing to do, retry to connect again */
> > }
>
> This doesn't look right. If SSL_connect() fails due to an NBIO event
> then you should get SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE back. If
> you get SSL_ERROR_SYSCALL then something bad happened and you should not
> retry. Could you add some logging here? I'm wondering whether you are
> ending up here but missing it and looping around again.
>
> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


4.pcap
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi,

As per the suggestion from openssl documentation whenever the SSL API
returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, The calling process
then must repeat the call after taking appropriate action to satisfy the
needs of SSL_connect().

I am copying the code bits here,

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

/* Initiate SSL Handshake */
aRetValue = SSL_connect(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);-->
Function is copied below*

  /* Nothing to do, retry to connect again*/
  LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect() fails to connect "
  "need to retry, returned error code %d , retry ? %s",
ivLink->getLinkId(), aTlsError, retry?"true":"false");
}
break;

case SSL_ERROR_SYSCALL:

if (EWOULDBLOCK == errno || EAGAIN == errno)
{
  /* Nothing to do, retry to connect again */
}
else
{
  int aRet = ERR_get_error_line(, );

  LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d , "
"Socket Id %d, Linux Error Code %d",ivLink->getLinkId(), aFile, aLine,
getFd(), errno);

  LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect () :: Result Code : %d
",ivLink->getLinkId(), aTlsError);

  retry = false;
}

break;

default:
{
  int aRet = ERR_get_error_line(, );

  LOGG_DBUG(Logger::M3UA_LOG,"Link-%d (SSL_connect) Failed to connect to
server, "
" Socket Id %d, Return Value %d ", ivLink->getLinkId(), getFd(), aTlsError);

  LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d ,
Linux Error Code %d",ivLink->getLinkId(), aFile, aLine, errno);

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


bool TlsAssociation::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 = getFd();

FD_ZERO ();
FD_ZERO ();
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;
}



Thanks,
Mahesh G S



On Tue, Nov 14, 2017 at 4:01 PM, Graham Leggett <minf...@sharp.fm> wrote:

> On 14 Nov 2017, at 12:00 PM, mahesh gs <mahesh...@gmail.com> wrote:
>
> We have application that provide DTLS security for SCTP connections.
> During our testing we found that API "*SSL_connect* " fail and always
> returns SSL_ERROR_WANT_READ which causes infinite loop in the application.
>
>
> Are you properly handling that SSL_ERROR_WANT_READ, or are you ignoring it?
>
> The message isn’t an error (the symbol was misnamed), it just means
> openssl is asking you permission to read. If your code is saying "yes
> openssl you may read" when you actually aren’t ready you’ll end up in an
> infinite loop.
>
> Regards,
> Graham
> —
>
>
> --
> 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

[openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application

[mahesh gs]

Hi All,

We have application that provide DTLS security for SCTP connections. During
our testing we found that API "*SSL_connect* " fail and always returns
SSL_ERROR_WANT_READ which causes infinite loop in the application.

Scenario:

1) On Server side "Client Certificate Request" is enabled by setting the
SSL context as shown below

SSL_CTX_set_verify(ctx,
SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);

2) On client side we have not configured the public certificate.


*Logs:*

[10/14/0117 15:05:06] F42C2700 Link-2 (SSL_accept) Failed to accept
new connection,  Socket Id 65, Return Value 1
[10/14/0117 15:05:06] F42C2700 Link-2 SSL File :*
ssl/statem/statem_srvr.c *, Line number : *2882 *, Linux Error Code 0
[10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true

*<<< SSL_connect() always returns error code 2 that leeds to infinite loop
in application >>>*

Attaching PCAP file for your reference.

*Thanks,*
*Mahesh G S*


connect.pcap
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Graceful shutdown of TLS connection for blocking sockets

[mahesh gs]

Hi All,

I have query regarding the SSL_read on blocking socket. How to come out of
blocking SSL_read when we have to close the connection ?

As per the documentation SSL_read will only return if there is any data or
an error occurred.

 "If the underlying BIO is *blocking*, SSL_read() will only return, *once
the read operation has been finished or an error occurred,* except when a
renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur"

I am trying following methods

*method 1:*

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application.
Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is
dangerous as calling SSL_shutdown and SSL_read from different threads on
same context can lead to undefined behaviour.

*method 2:*

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application.
shutdown the underlying TCP socket using system command (shutdown
(socket_id, SHUT_WR)) that cause the SSL_read to unblock.
3) Thread - 1 unwind and close the TCP socket (using close(socket_id)).
thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by
thread - 2 for write operation. As per my understanding this violates the
TLS standard because of not sending out the close notify handshake.

How to ensure to come out of blocking SSL_read and initiate SSL_shutdown
from same thread?

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

[openssl-users] Query regarding the SCTP events for DTLS connections

[mahesh gs]

Hi,

We have an application which has SCTP connections we have secured the SCTP
connections using the openssl DTLS. DTLS is working as expected other than
the SCTP events.

We use the API "BIO_new_dgram_sctp" to create a BIO objects and we register
a callback function to openssl using API "BIO_dgram_sctp_notification_cb"
to populate the SCTP events. I observe that openssl enables only
authentication related events, do not enable any other events like
association, shutdown etc.

Code snippet from the API "BIO_new_dgram_sctp":

event.sctp_authentication_event = 1;

ret =
setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, ,
   sizeof(struct sctp_event_subscribe));
if (ret < 0) {
BIO_vfree(bio);
return (NULL);
}

Is there any specific reason for just enabling the authentication events ?

If yes, is there any way applications register for other events like
shutdown, association etc. We have a requirement where based on the SCTP
events application executes certain business logic.

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

[openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384

[mahesh gs]

Hi All,

I am using openssl version 01.01.00f for providing TLS and DTLS security
for TCP and SCTP connection for our application. I have query regarding the
"Ciphers" that are accepted by the SSL_CTX_set_cpiher_list API. The list of
ciphers that are supported by openssl version 01.01.00f that is output of
command "openssl ciphers -v" is as listed down below. When i try to set
these ciphers through API "SSL_CTX_set_cipher_list" returns success for
some and failure for some other ciphers.

For example if i set "ECDHE-RSA-AES256-GCM-SHA384" API returns success but
if i set "DHE-DSS-AES256-GCM-SHA384" or "RC4-MD5" API returns failure. My
query is what are the accepted ciphers ? and what is the reason behind not
accepting some of them?

*openssl ciphers -v*

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
 Mac=SHA384
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH   Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)
 Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA  SSLv3 Kx=PSK  Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
 Mac=SHA256
ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHASSLv3 Kx=DH   Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 Kx=DH   Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH   Au=DSS  Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)
 Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA 

[openssl-users] Existing connections on certification expires

[mahesh gs]

Hello All,

We are using openssl for providing the secured communication for our
application. I have some basic queries about the openssl behaviour.

1) What happens to the existing SSL connections on certification expiry?
Does the openssl disconnects the existing connection?

2) How can i get the list of ciphers supported by openssl 01.01.0f ?

These question looks to be very basic but i could not find any concrete
information regarding the same googling.

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[mahesh gs]

On Tue, May 2, 2017 at 2:36 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 02/05/17 06:59, mahesh gs wrote:
> > Hi Matt,
> >
> > Sorry for delayed response. I was on leave.
> >
> > Yes, ours is a library and we do not wish to ignore the signal process
> > wide because the consumer of our library (application) might want to
> > handle the SIGPIPE for there own socket handling.
>
> Could you use pthread_sigmask() to only block SIGPIPE for the current
> thread (perhaps unblocking it again before returning control back to the
> caller of your library)?
>



> Thanks for your suggestion. We will try to adapt this work around.
>
>
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell <m...@openssl.org
> > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 27/04/17 11:56, mahesh gs wrote:
> > > Hi,
> > >
> > > We are using Openssl for establish a secure communications for both
> > > TCP/SCTP connections.
> > >
> > > In our application it is possible that remote end forcefully
> disconnect
> > > the connection due to which
> > >
> > > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl
> > >
> > > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP
> socket
> > > layer) ?
> >
> > No, there is no option to do that at the moment.
> >
> > >
> > > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as
> it is
> > > not supported by LINUX
> > >
> > > and also we are unable to stop the SIGPIPE with function call
> > > signal(SIGPIPE, SIG_IGN).
> >
> > Unable because you want SIGPIPE for other areas of your application?
> Or
> > for some other reason?
> >
> > Matt
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> > <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> --
> 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

[mahesh gs]

On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <
michael.tue...@lurchi.franken.de> wrote:

> > On 20. Apr 2017, at 20:01, mahesh gs <mahesh...@gmail.com> wrote:
> >
> > Hi,
> >
> > This issue occur purely based on the time (sequence of events) at which
> SSL read_state_machine enter the post processing of certificate verify
> which is received from client.
> >
> > Handshake works fine if the certificate verify post processing is done
> before the next message arrives at SCTP socket layer (In your case may be
> there is a delay in receiving the next message at SCTP layer). Handshake
> works fine even in my environment some times.
> Can you try the attached patch and report if it fixes the issue for you?
>

I have tried with the patch provided by Matt. Our test results are
successful. Issue is fixed with the patch.

>
> Best regards
> Michael
>
>
>
> >
> >
> > I added some debug statements, below is the debug statements.
> >
> >
> > Debug statements when the handshake does not work
> >
> > 
> >
> > Length of the next packet (Cipher spec change) is exactly 14 as i
> mentioned  in - https://github.com/openssl/openssl/issues/3251
> >
> > Debug logs when the handshake is successful
> >
> > 
> >
> > If no message is waiting to be received at socket layer then handshake
> is successful. If message is waiting to be received at socket layer then
> the handshake will never be completed.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <
> martin.brej...@mavenir.com> wrote:
> >
> >
> > Matt Caswell wrote on 04/20/2017 03:23 PM:
> > >
> > >
> > > On 20/04/17 14:19, Martin Brejcha wrote:
> > >>
> > >>
> > >> Matt Caswell wrote on 04/20/2017 01:29 PM:
> > >>>
> > >>>
> > >>> On 20/04/17 12:26, mahesh gs wrote:
> > >>>> Hi Matt,
> > >>>>
> > >>>> Yes I raised github case for the same issue. I also tried running
> this
> > >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
> > >>>> handshake is successful with the latest SNAPSHOT code which is not
> an
> > >>>> official release.
> > >>>>
> > >>>> I checked the github repo history and observer that during commits
> on
> > >>>> (11 th Jan) as a part of "Move state machine knowledge out of the
> record
> > >>>> layer".  "renegotiate" bit that is set to "2" in function
> > >>>> "tls_post_process_client_hello" has been removed. May be that is
> causing
> > >>>> the call flow to be successful in the latest SNAPSHOT release.
> > >>>>
> > >>>> I am assuming commits that are done on 11th Jan or later are not
> part of
> > >>>> release openssl 01.01.00e
> > >>>
> > >>> Ah. No. That commit is in the dev branch only (scheduled for version
> > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why
> that
> > >>> commit might help things, but probably a different solution is more
> > >>> appropriate for 1.1.0.
> > >>>
> > >>> I'm looking at this issue at the moment.
> > >>>
> > >>> Matt
> > >>>
> > >>
> > >> hi,
> > >>
> > >> btw: I've tested similar scenario and handshake works fine.
> > >> test env: client and server on different VMs (rhel7.2, openssl
> 1.1.0e, non-blocking sockets and segmented certificate)
> > >> So, it should work also with 1.1.0e version.
> > >
> > > Thanks. Did your handshake include client auth? I think this issue only
> > > arises in that case.
> > >
> > > Matt
> > >
> > >
> >
> > yes, client auth with segmented certificate has been included.
> >
> > Martin
> >
> >
> >
> > >
> > >
> >
> > --
> > 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
>
>
> --
> 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 MSG_NOSIGNAL with SSL_Write

[mahesh gs]

Hi Matt,

Sorry for delayed response. I was on leave.

Yes, ours is a library and we do not wish to ignore the signal process wide
because the consumer of our library (application) might want to handle the
SIGPIPE for there own socket handling.

Thanks,
Mahesh G S

On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 27/04/17 11:56, mahesh gs wrote:
> > Hi,
> >
> > We are using Openssl for establish a secure communications for both
> > TCP/SCTP connections.
> >
> > In our application it is possible that remote end forcefully disconnect
> > the connection due to which
> >
> > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl
> >
> > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> > layer) ?
>
> No, there is no option to do that at the moment.
>
> >
> > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> > not supported by LINUX
> >
> > and also we are unable to stop the SIGPIPE with function call
> > signal(SIGPIPE, SIG_IGN).
>
> Unable because you want SIGPIPE for other areas of your application? Or
> for some other reason?
>
> Matt
> --
> 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

[openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[mahesh gs]

Hi,

We are using Openssl for establish a secure communications for both
TCP/SCTP connections.

In our application it is possible that remote end forcefully disconnect the
connection due to which

SSL_Write raises a SIGPIPE which we want to suppress. Does openssl

provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
layer) ?

Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is not
supported by LINUX

and also we are unable to stop the SIGPIPE with function call
signal(SIGPIPE, SIG_IGN).


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

Re: [openssl-users] Query regarding DTLS handshake

[mahesh gs]

Hi Matt,

Yes I raised github case for the same issue. I also tried running this call
flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and handshake is
successful with the latest SNAPSHOT code which is not an official release.

I checked the github repo history and observer that during commits on (11
th Jan) as a part of "Move state machine knowledge out of the record
layer".  "renegotiate" bit that is set to "2" in function
"tls_post_process_client_hello" has been removed. May be that is causing
the call flow to be successful in the latest SNAPSHOT release.

I am assuming commits that are done on 11th Jan or later are not part of
release openssl 01.01.00e


Thanks,
Mahesh G S

On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell <m...@openssl.org> wrote:

> For those following this discussion Mahesh has created a github issue
> with much more detail (at least I am assuming this is the same issue):
>
> https://github.com/openssl/openssl/issues/3251
>
> Matt
>
>
> On 18/04/17 21:17, Michael Tuexen wrote:
> >> On 13. Apr 2017, at 11:11, mahesh gs <mahesh...@gmail.com> 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.
> > Which OS are you using? With a test program I could reproduce
> SSL_accept() returning SSL_ERROR_WANT_READ under FreeBSD,
> > but not under Linux. Haven't figured out what the problem is. So if you
> are using FreeBSD we might experience the same problem...
> >
> > 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
>
-- 
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 

Re: [openssl-users] DTLS for SCTP connections

[mahesh gs]

Hi,

I did some more search regarding this problem and found that its a defect
in kernel SCTP. OS was built with linux kernel version 2.6 which is quite
old.

Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/

I upgraded to RHEL 7.1 and the problem resolved.

Thanks for your support.

On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs <mahesh...@gmail.com> wrote:

> Hi Michael,
>
> I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and
> openssl version is 1.1.0.
>
> SCTP version :
>
> [root@localhost DIAMETER]# rpm -qa | grep -i "sctp"
> *lksctp-tools-1.0.10-5.el6.x86_64*
> [root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64
> Name: lksctp-tools Relocations: (not relocatable)
> Version : 1.0.10Vendor: Red Hat, Inc.
> Release : 5.el6 *Build Date: Mon 22 Feb 2010
> 12:24:33 PM CET*
> Install Date: Wed 08 Feb 2017 10:08:12 AM CET  Build Host:
> hs20-bc1-2.build.redhat.com
> Group   : System Environment/Libraries   Source RPM:
> lksctp-tools-1.0.10-5.el6.src.rpm
> Size: 203688   License: GPLv2 and GPLv2+
> and LGPLv2 and BSD
> Signature   : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID
> 199e2f91fd431d51
> Packager: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> URL : http://lksctp.sourceforge.net
> Summary : User-space access to Linux Kernel SCTP
> Description :
> This is the lksctp-tools package for Linux Kernel SCTP (Stream Control
> Transmission Protocol) Reference Implementation.
>
>
>
> Thanks,
> Mahesh G S
>
> On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen <Michael.Tuexen@lurchi.
> franken.de> wrote:
>
>> > On 22 Feb 2017, at 07:47, mahesh gs <mahesh...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > Thank you for sharing the sample code.
>> >
>> > I tried running SCTP DTLS Echo server and client. I am facing strange
>> problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs
>> on the server side.
>> >
>> > Client side back trace
>> >
>> > (gdb) bt
>> > #0  0x003db4c0ea10 in __recvmsg_nocancel () from
>> /lib64/libpthread.so.0
>> > #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073
>> "\026\376\377", outl=17741) at bss_dgram.c:1178
>> > #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073,
>> outl=17741) at bio_lib.c:210
>> > #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741,
>> extend=) at s3_pkt.c:258
>> > #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
>> > #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22,
>> buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
>> > #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70,
>> st1=, stn=4449, max=30, ok=0x7ffee09c)
>> > at d1_both.c:908
>> > #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448,
>> stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
>> > #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at
>> s3_clnt.c:2458
>> > #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
>> > #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
>> > #11 0x00403573 in main ()
>> >
>> >
>> > Server side back trace
>> >
>> > (gdb) info threads
>> >   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg ()
>> from /lib64/libpthread.so.0
>> > * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept ()
>> from /lib64/libpthread.so.0
>> > (gdb) t 2
>> > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0
>> 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
>> > (gdb) bt
>> > #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
>> > #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry
>> (b=0x70001930) at bss_dgram.c:1803
>> > #2  0x77dc7830 in dtls1_accept (s=0x78c0) at
>> d1_srvr.c:403
>> > #3  0x004021ee in connection_handle(void*) ()
>> > #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
>> > #5  0x003db48e890d in clone () from /lib64/libc.so.6
>> > (gdb)
>> >
>> >
>> > I am also attaching the wireshark trace (port 4443) and a server key
>> for decoding wireshark.
>> >
>> &

Re: [openssl-users] DTLS for SCTP connections

[mahesh gs]

Hi Michael,

I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and
openssl version is 1.1.0.

SCTP version :

[root@localhost DIAMETER]# rpm -qa | grep -i "sctp"
*lksctp-tools-1.0.10-5.el6.x86_64*
[root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64
Name: lksctp-tools Relocations: (not relocatable)
Version : 1.0.10Vendor: Red Hat, Inc.
Release : 5.el6 *Build Date: Mon 22 Feb 2010
12:24:33 PM CET*
Install Date: Wed 08 Feb 2017 10:08:12 AM CET  Build Host:
hs20-bc1-2.build.redhat.com
Group   : System Environment/Libraries   Source RPM:
lksctp-tools-1.0.10-5.el6.src.rpm
Size: 203688   License: GPLv2 and GPLv2+
and LGPLv2 and BSD
Signature   : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID
199e2f91fd431d51
Packager: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://lksctp.sourceforge.net
Summary : User-space access to Linux Kernel SCTP
Description :
This is the lksctp-tools package for Linux Kernel SCTP (Stream Control
Transmission Protocol) Reference Implementation.



Thanks,
Mahesh G S

On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen <
michael.tue...@lurchi.franken.de> wrote:

> > On 22 Feb 2017, at 07:47, mahesh gs <mahesh...@gmail.com> wrote:
> >
> > Hi,
> >
> > Thank you for sharing the sample code.
> >
> > I tried running SCTP DTLS Echo server and client. I am facing strange
> problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs
> on the server side.
> >
> > Client side back trace
> >
> > (gdb) bt
> > #0  0x003db4c0ea10 in __recvmsg_nocancel () from
> /lib64/libpthread.so.0
> > #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073
> "\026\376\377", outl=17741) at bss_dgram.c:1178
> > #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073,
> outl=17741) at bio_lib.c:210
> > #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741,
> extend=) at s3_pkt.c:258
> > #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
> > #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22,
> buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
> > #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70,
> st1=, stn=4449, max=30, ok=0x7ffee09c)
> > at d1_both.c:908
> > #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448,
> stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
> > #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at
> s3_clnt.c:2458
> > #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
> > #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
> > #11 0x00403573 in main ()
> >
> >
> > Server side back trace
> >
> > (gdb) info threads
> >   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg ()
> from /lib64/libpthread.so.0
> > * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept ()
> from /lib64/libpthread.so.0
> > (gdb) t 2
> > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0
> 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > (gdb) bt
> > #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930)
> at bss_dgram.c:1803
> > #2  0x77dc7830 in dtls1_accept (s=0x78c0) at
> d1_srvr.c:403
> > #3  0x004021ee in connection_handle(void*) ()
> > #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
> > #5  0x003db48e890d in clone () from /lib64/libc.so.6
> > (gdb)
> >
> >
> > I am also attaching the wireshark trace (port 4443) and a server key for
> decoding wireshark.
> >
> > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> >
> > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> -l 50 -n 5 16.181.38.161
> >
> > Thanks in advance for your valuable input
> I've CCed Irene, who did some testing recently on FreeBSD, where the
> implementation works.
> The server is waiting for a sender dry event which it should get.
>
> Which version of OpenSSL are you using and which OS are you using?
>
> Best regards
> Michael
> >
> > Regards,
> > Mahesh G S
> >
> >
> >
> > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen <Michael.Tuexen@lurchi.
> franken.de> wrote:
> > > On 21 Feb 2017, at 09:53, mahesh gs <mahesh...@gm

[openssl-users] DTLS for SCTP connections

[mahesh gs]

Hi,

We have a client, server applications that is using SCTP as a transport
protocol. We have to secure the connections using DTLS. I am using openssl
version 1.0.2 which supports DTLS. But the problem i am facing is usage of
DTLS SCTP related API's. Openssl documentation does not clearly explain all
the SCTP related API's and usage sequence.

I have tried going though internet and found most of the sites redirect to
one link for SCTP DTLS sample code. But this link is not working.

http://sctp.fh-muenster.de/dtls-samples.html

If any of you has an sample code of DTLS adaptation for SCTP. It would
immensely help me for my work.

Looking forward to your valuable inputs.

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