Query regarding DTLS handshake

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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



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

testcode.txt (10K) Download Attachment
proxy.cap (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
Hi,

Further to this, I enabled the openssl alerts. I observed the following issue.

On Client side i see error in write finish and this already is repeated continuously

Inline image 1

On the server side , server fails in read certificate verify. 

Inline image 2

Can anyone help me to analyze the code and the reason for this issue ?

Thanks,
Mahesh G S


On Thu, Apr 13, 2017 at 2:41 PM, mahesh gs <[hidden email]> 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.

Thanks,
Mahesh G S




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Matt Caswell-2
In reply to this post by mahesh gs


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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Michael Tuexen-4
In reply to this post by mahesh gs
> On 13. Apr 2017, at 11:11, mahesh gs <[hidden email]> 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
>
>
> <testcode.txt><proxy.cap>--
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Martin Brejcha
In reply to this post by Matt Caswell-2


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
>

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

0xB42AB632.asc (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Michael Tuexen-4
> On 13. Apr 2017, at 19:26, Martin Brejcha <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Matt Caswell-2
In reply to this post by Martin Brejcha


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


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

signature.asc (491 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Help with ssl error

Joseph Southwell
In reply to this post by Matt Caswell-2
Version 1.1 openssl

openssl.exe s_client -connect hostname:16370 -starttls ftp
CONNECTED(00000104)
877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The host I am connecting to apparently only supports the following 2 ciphers:
RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

What should I do to make this work?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Viktor Dukhovni

> On Apr 14, 2017, at 9:48 AM, Joseph Southwell <[hidden email]> wrote:
>
> Version 1.1 openssl
>
> openssl.exe s_client -connect hostname:16370 -starttls ftp
> 877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The remote host sent an "insufficient security" TLS alert.

> The host I am connecting to apparently only supports the following 2 ciphers:
> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA
>
> What should I do to make this work?

Perhaps it is expecting a client certificate?  Retry with:

 $ openssl s_client -state -msg -connect hostname:16370 -starttls ftp

and see whether it solicited a client certificate.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
In reply to this post by Matt Caswell-2
Hi All,

Sorry for delayed response, thank you all for responding to my query.

1) We are using non-blocking sockets on RHEL 7.0 machine with the kernel version 3.10.

2) When we run client and server in the same machine it works fine. Client and server able to exchange the data without any issues. But if we run client and server in different machines, we face this problem.

Server side logs when we run the server and client in same machine

Inline image 1

Client side log when we run the server and client in the same machine.

Inline image 2


3) as suggested by Matt i disable the client auth when client-server run in different machines and surprisingly the TLS negotiation is successful. That leads me to suspect on segmentation and reassembly.

Server side logs when the client auth is disabled

Inline image 3 


Client side logs when the client auth is disabled.

Inline image 4


I took a wireshark trace and found that the server is able to receive the client certificate in 3 fragments and responding with the proper sack with right TSN. But server do not respond with its own certificate after that. I have attached the wireshark trace for the same. Path MTU in both the systems set to 1500.


I took the strace of the calls between server and client but i could not figure out anything with the strace. I have attached the same in the mail. strace summary table is as below.

^C% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 33.71    0.000326           3        99        76 open
 18.10    0.000175           3        54           mmap
 15.10    0.000146           4        37           mprotect
  9.72    0.000094          13         7           recvmsg
  5.07    0.000049           2        26           read
  4.03    0.000039           2        24           close
  3.93    0.000038           2        17           fstat
  3.83    0.000037          19         2           sendto
  1.24    0.000012           3         4         3 stat
  0.93    0.000009           2         5           brk
  0.62    0.000006           6         1           munmap
  0.52    0.000005           3         2           futex
  0.41    0.000004           1         3           rt_sigaction
  0.41    0.000004           4         1         1 access
  0.41    0.000004           1         3           socket
  0.41    0.000004           4         1           execve
  0.31    0.000003           3         1           set_tid_address
  0.21    0.000002           1         3           rt_sigprocmask
  0.21    0.000002           1         2           bind
  0.21    0.000002           1         3           getsockname
  0.21    0.000002           2         1           getrlimit
  0.21    0.000002           2         1           arch_prctl
  0.21    0.000002           2         1           set_robust_list
  0.00    0.000000           0        25           write
  0.00    0.000000           0         1           ioctl
  0.00    0.000000           0         1           listen
  0.00    0.000000           0         6           clone
  0.00    0.000000           0         4           epoll_ctl
  0.00    0.000000           0         1           timerfd_create
  0.00    0.000000           0         1           eventfd2
  0.00    0.000000           0         1           epoll_create1
------ ----------- ----------- --------- --------- ----------------
100.00    0.000967                   338        80 total


I am new to openssl code could not figure out how to debug the issue at socket layer. Can some one help me to understand how to go forward to resolve this issue ?


Thanks and Regards,
Mahesh G S

On Fri, Apr 14, 2017 at 3:32 AM, Matt Caswell <[hidden email]> wrote:


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


--
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

strace.txt (36K) Download Attachment
server.cap (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
Hi All,

Adding to this, When we changed the path MTU of the source and destination VM's we could see the SSL connection is successful and application data getting exchanged which confirms that there is issue in segmentation and reassembly of packets.


Do we have some system configuration that need to be enabled for DTLS ? as i mentioned in my previous mails, TLS negotiation is successful without changing path MTU but not DTLS.


Thanks,
Mahesh G S 

On Mon, Apr 17, 2017 at 12:36 PM, mahesh gs <[hidden email]> wrote:
Hi All,

Sorry for delayed response, thank you all for responding to my query.

1) We are using non-blocking sockets on RHEL 7.0 machine with the kernel version 3.10.

2) When we run client and server in the same machine it works fine. Client and server able to exchange the data without any issues. But if we run client and server in different machines, we face this problem.

Server side logs when we run the server and client in same machine

Inline image 1

Client side log when we run the server and client in the same machine.

Inline image 2


3) as suggested by Matt i disable the client auth when client-server run in different machines and surprisingly the TLS negotiation is successful. That leads me to suspect on segmentation and reassembly.

Server side logs when the client auth is disabled

Inline image 3 


Client side logs when the client auth is disabled.

Inline image 4


I took a wireshark trace and found that the server is able to receive the client certificate in 3 fragments and responding with the proper sack with right TSN. But server do not respond with its own certificate after that. I have attached the wireshark trace for the same. Path MTU in both the systems set to 1500.


I took the strace of the calls between server and client but i could not figure out anything with the strace. I have attached the same in the mail. strace summary table is as below.

^C% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 33.71    0.000326           3        99        76 open
 18.10    0.000175           3        54           mmap
 15.10    0.000146           4        37           mprotect
  9.72    0.000094          13         7           recvmsg
  5.07    0.000049           2        26           read
  4.03    0.000039           2        24           close
  3.93    0.000038           2        17           fstat
  3.83    0.000037          19         2           sendto
  1.24    0.000012           3         4         3 stat
  0.93    0.000009           2         5           brk
  0.62    0.000006           6         1           munmap
  0.52    0.000005           3         2           futex
  0.41    0.000004           1         3           rt_sigaction
  0.41    0.000004           4         1         1 access
  0.41    0.000004           1         3           socket
  0.41    0.000004           4         1           execve
  0.31    0.000003           3         1           set_tid_address
  0.21    0.000002           1         3           rt_sigprocmask
  0.21    0.000002           1         2           bind
  0.21    0.000002           1         3           getsockname
  0.21    0.000002           2         1           getrlimit
  0.21    0.000002           2         1           arch_prctl
  0.21    0.000002           2         1           set_robust_list
  0.00    0.000000           0        25           write
  0.00    0.000000           0         1           ioctl
  0.00    0.000000           0         1           listen
  0.00    0.000000           0         6           clone
  0.00    0.000000           0         4           epoll_ctl
  0.00    0.000000           0         1           timerfd_create
  0.00    0.000000           0         1           eventfd2
  0.00    0.000000           0         1           epoll_create1
------ ----------- ----------- --------- --------- ----------------
100.00    0.000967                   338        80 total


I am new to openssl code could not figure out how to debug the issue at socket layer. Can some one help me to understand how to go forward to resolve this issue ?


Thanks and Regards,
Mahesh G S

On Fri, Apr 14, 2017 at 3:32 AM, Matt Caswell <[hidden email]> wrote:


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


--
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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
Hi All,

We built openssl code by enabling debug options and found that in TLS_ST_SR_CERT_VRFY state openssl checks  for the following conditions

1) If the datagram type is SCTP : : In this case it is DTLS and set to 1.

2) Value of s->renegotiate  : : in this case the value was set to 2. I guess this is set in post processing function of client hello.

3) If any sctp message is waiting to be received : : In this case this was true (1). When we debug inside the BIO_dgram_sctp_msg_waiting. We observed that the recvmsg system call returning the size (n = 14 bytes) that is exactly size of the next  package (Auth Change Cipher Spec) as shown in the below screenshot. 

So this function return "WORK_MORE_A" to the caller "read_state_machine" which intern returns SUB_STATE_ERROR. And this flow keeps repeating.
And also we observed that this issue is something to do with the timing of the messages received at SCTP layer. If the post processing message function executed before the next message arrives at SCTP layer, then the SSL negotiation is successful else SSL negotiation hangs at TLS_ST_SR_CERT_VEFY state.


Can someone who is familiar with the openssl code give us some insights about what is the logic behind the if check in TLS_ST_SR_CERT_VRFY state in post processing function ?

Inline image 1

Inline image 2



Inline image 3



On Mon, Apr 17, 2017 at 4:14 PM, mahesh gs <[hidden email]> wrote:
Hi All,

Adding to this, When we changed the path MTU of the source and destination VM's we could see the SSL connection is successful and application data getting exchanged which confirms that there is issue in segmentation and reassembly of packets.


Do we have some system configuration that need to be enabled for DTLS ? as i mentioned in my previous mails, TLS negotiation is successful without changing path MTU but not DTLS.


Thanks,
Mahesh G S 

On Mon, Apr 17, 2017 at 12:36 PM, mahesh gs <[hidden email]> wrote:
Hi All,

Sorry for delayed response, thank you all for responding to my query.

1) We are using non-blocking sockets on RHEL 7.0 machine with the kernel version 3.10.

2) When we run client and server in the same machine it works fine. Client and server able to exchange the data without any issues. But if we run client and server in different machines, we face this problem.

Server side logs when we run the server and client in same machine

Inline image 1

Client side log when we run the server and client in the same machine.

Inline image 2


3) as suggested by Matt i disable the client auth when client-server run in different machines and surprisingly the TLS negotiation is successful. That leads me to suspect on segmentation and reassembly.

Server side logs when the client auth is disabled

Inline image 3 


Client side logs when the client auth is disabled.

Inline image 4


I took a wireshark trace and found that the server is able to receive the client certificate in 3 fragments and responding with the proper sack with right TSN. But server do not respond with its own certificate after that. I have attached the wireshark trace for the same. Path MTU in both the systems set to 1500.


I took the strace of the calls between server and client but i could not figure out anything with the strace. I have attached the same in the mail. strace summary table is as below.

^C% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 33.71    0.000326           3        99        76 open
 18.10    0.000175           3        54           mmap
 15.10    0.000146           4        37           mprotect
  9.72    0.000094          13         7           recvmsg
  5.07    0.000049           2        26           read
  4.03    0.000039           2        24           close
  3.93    0.000038           2        17           fstat
  3.83    0.000037          19         2           sendto
  1.24    0.000012           3         4         3 stat
  0.93    0.000009           2         5           brk
  0.62    0.000006           6         1           munmap
  0.52    0.000005           3         2           futex
  0.41    0.000004           1         3           rt_sigaction
  0.41    0.000004           4         1         1 access
  0.41    0.000004           1         3           socket
  0.41    0.000004           4         1           execve
  0.31    0.000003           3         1           set_tid_address
  0.21    0.000002           1         3           rt_sigprocmask
  0.21    0.000002           1         2           bind
  0.21    0.000002           1         3           getsockname
  0.21    0.000002           2         1           getrlimit
  0.21    0.000002           2         1           arch_prctl
  0.21    0.000002           2         1           set_robust_list
  0.00    0.000000           0        25           write
  0.00    0.000000           0         1           ioctl
  0.00    0.000000           0         1           listen
  0.00    0.000000           0         6           clone
  0.00    0.000000           0         4           epoll_ctl
  0.00    0.000000           0         1           timerfd_create
  0.00    0.000000           0         1           eventfd2
  0.00    0.000000           0         1           epoll_create1
------ ----------- ----------- --------- --------- ----------------
100.00    0.000967                   338        80 total


I am new to openssl code could not figure out how to debug the issue at socket layer. Can some one help me to understand how to go forward to resolve this issue ?


Thanks and Regards,
Mahesh G S

On Fri, Apr 14, 2017 at 3:32 AM, Matt Caswell <[hidden email]> wrote:


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


--
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

server.cap (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Joseph Southwell
In reply to this post by Viktor Dukhovni
It doesn’t look like it requested a client certificate to me.

openssl110e>openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 -starttls ftp
CONNECTED(00000104)
SSL_connect:before SSL initialization
>>> ??? [length 0005]
    16 03 01 00 ab
>>> TLS 1.2Handshake [length 00ab], ClientHello
    01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
    59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
    81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
    a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
    6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
    13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
    ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
    0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
    0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
    03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
    02 02 03 00 16 00 00 00 17 00 00
SSL_connect:SSLv3/TLS write client hello
<<< ??? [length 0005]
    15 03 02 00 02
<<< TLS 1.2Alert [length 0002], fatal insufficient_security
    02 47
SSL3 alert read:fatal:insufficient security
SSL_connect:error in SSLv3/TLS write client hello
3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 88 bytes and written 186 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1492518024
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
 
On Apr 14, 2017, at 2:49 PM, Viktor Dukhovni <[hidden email]> wrote:


On Apr 14, 2017, at 9:48 AM, Joseph Southwell <[hidden email]> wrote:

Version 1.1 openssl

openssl.exe s_client -connect hostname:16370 -starttls ftp
877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The remote host sent an "insufficient security" TLS alert.

The host I am connecting to apparently only supports the following 2 ciphers:
RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

What should I do to make this work?

Perhaps it is expecting a client certificate?  Retry with:

$ openssl s_client -state -msg -connect hostname:16370 -starttls ftp

and see whether it solicited a client certificate.

--
Viktor.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Viktor Dukhovni
On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote:

> It doesn’t look like it requested a client certificate to me.

Correct, the server alert was returned immediately in response
to the TLS ClientHello.

> $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 -starttls ftp
> CONNECTED(00000104)
> SSL_connect:before SSL initialization
> >>> ??? [length 0005]
>     16 03 01 00 ab
> >>> TLS 1.2Handshake [length 00ab], ClientHello
>     01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
>     59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
>     81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
>     a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
>     6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
>     13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
>     ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
>     0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
>     0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
>     03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
>     02 02 03 00 16 00 00 00 17 00 00
> SSL_connect:SSLv3/TLS write client hello
> <<< ??? [length 0005]
>     15 03 02 00 02
> <<< TLS 1.2Alert [length 0002], fatal insufficient_security
>     02 47
> SSL3 alert read:fatal:insufficient security
> SSL_connect:error in SSLv3/TLS write client hello
> 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The ClientHello decodes via tshark as:

Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 171
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 167
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: Jun  5, 2064 16:07:35.000000000 AEST
                Random Bytes: 9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0...
            Session ID Length: 0
            Cipher Suites Length: 56
            Cipher Suites (28 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
                Cipher Suite: Unknown (0xcca9)
                Cipher Suite: Unknown (0xcca8)
                Cipher Suite: Unknown (0xccaa)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 70
            Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)
            Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 10
                Elliptic Curves Length: 8
                Elliptic curves (4 curves)
                    Elliptic curve: Unknown (0x001d)
                    Elliptic curve: secp256r1 (0x0017)
                    Elliptic curve: secp521r1 (0x0019)
                    Elliptic curve: secp384r1 (0x0018)
            Extension: SessionTicket TLS
                Type: SessionTicket TLS (0x0023)
                Length: 0
                Data (0 bytes)
            Extension: signature_algorithms
                Type: signature_algorithms (0x000d)
                Length: 32
                Signature Hash Algorithms Length: 30
                Signature Hash Algorithms (15 algorithms)
                    Signature Hash Algorithm: 0x0601
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0602
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0603
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0501
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0502
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0503
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0401
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0402
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0403
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0301
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0302
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0303
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0201
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0202
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0203
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
            Extension: Unknown 22
                Type: Unknown (0x0016)
                Length: 0
                Data (0 bytes)
            Extension: Unknown 23
                Type: Unknown (0x0017)
                Length: 0
                Data (0 bytes)

The code-points unknown to the version of tshark used are:

    - Cipher 0xcca9: ECDHE-ECDSA-Chacha20-Poly1305-SHA256
    - Cipher 0xcca8: ECDHE-RSA-Chacha20-Poly1305-SHA256
    - Cipher 0xccaa: DHE-RSA-Chacha20-Poly1305-SHA256
    - Elliptic curve 0x1d: ECDH_x25519
    - Extension 22: encrypt-then-mac
    - Extension 23: extended-master-secret

This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
be broadly interoperable.  The DEFAULT cipherlist includes only
AES, is there a chance that the server only supports RC4 and/or
3DES?

Try:

    $ openssl s_client -state -msg -cipher ALL \
        -connect ftp.echannel.banksys.be:16370 -starttls ftp

Capture a PCAP file of the traffic with

    # tcpdump -s0 -w /some/file tcp port 16370

and post the the decode from:

    $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
        sed -ne '/^Secure Sockets Layer/,/^$/p'

Or just attach the PCAP file to your follow-up message.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Jason Schultz

From the original question, it appears the server here only supports two cipher suites: 

RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA


This would explain the alert 71, which is the sent because there are no cipher suites in common.


From: openssl-users <[hidden email]> on behalf of Viktor Dukhovni <[hidden email]>
Sent: Tuesday, April 18, 2017 5:06 PM
To: [hidden email]
Subject: Re: [openssl-users] Help with ssl error
 
On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote:

> It doesn’t look like it requested a client certificate to me.

Correct, the server alert was returned immediately in response
to the TLS ClientHello.

> $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 -starttls ftp
> CONNECTED(00000104)
> SSL_connect:before SSL initialization
> >>> ??? [length 0005]
>     16 03 01 00 ab
> >>> TLS 1.2Handshake [length 00ab], ClientHello
>     01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
>     59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
>     81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
>     a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
>     6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
>     13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
>     ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
>     0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
>     0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
>     03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
>     02 02 03 00 16 00 00 00 17 00 00
> SSL_connect:SSLv3/TLS write client hello
> <<< ??? [length 0005]
>     15 03 02 00 02
> <<< TLS 1.2Alert [length 0002], fatal insufficient_security
>     02 47
> SSL3 alert read:fatal:insufficient security
> SSL_connect:error in SSLv3/TLS write client hello
> 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The ClientHello decodes via tshark as:

Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 171
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 167
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: Jun  5, 2064 16:07:35.000000000 AEST
                Random Bytes: 9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0...
            Session ID Length: 0
            Cipher Suites Length: 56
            Cipher Suites (28 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
                Cipher Suite: Unknown (0xcca9)
                Cipher Suite: Unknown (0xcca8)
                Cipher Suite: Unknown (0xccaa)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 70
            Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)
            Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 10
                Elliptic Curves Length: 8
                Elliptic curves (4 curves)
                    Elliptic curve: Unknown (0x001d)
                    Elliptic curve: secp256r1 (0x0017)
                    Elliptic curve: secp521r1 (0x0019)
                    Elliptic curve: secp384r1 (0x0018)
            Extension: SessionTicket TLS
                Type: SessionTicket TLS (0x0023)
                Length: 0
                Data (0 bytes)
            Extension: signature_algorithms
                Type: signature_algorithms (0x000d)
                Length: 32
                Signature Hash Algorithms Length: 30
                Signature Hash Algorithms (15 algorithms)
                    Signature Hash Algorithm: 0x0601
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0602
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0603
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0501
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0502
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0503
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0401
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0402
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0403
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0301
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0302
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0303
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0201
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0202
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0203
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
            Extension: Unknown 22
                Type: Unknown (0x0016)
                Length: 0
                Data (0 bytes)
            Extension: Unknown 23
                Type: Unknown (0x0017)
                Length: 0
                Data (0 bytes)

The code-points unknown to the version of tshark used are:

    - Cipher 0xcca9: ECDHE-ECDSA-Chacha20-Poly1305-SHA256
    - Cipher 0xcca8: ECDHE-RSA-Chacha20-Poly1305-SHA256
    - Cipher 0xccaa: DHE-RSA-Chacha20-Poly1305-SHA256
    - Elliptic curve 0x1d: ECDH_x25519
    - Extension 22: encrypt-then-mac
    - Extension 23: extended-master-secret

This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
be broadly interoperable.  The DEFAULT cipherlist includes only
AES, is there a chance that the server only supports RC4 and/or
3DES?

Try:

    $ openssl s_client -state -msg -cipher ALL \
        -connect ftp.echannel.banksys.be:16370 -starttls ftp

Capture a PCAP file of the traffic with

    # tcpdump -s0 -w /some/file tcp port 16370

and post the the decode from:

    $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
        sed -ne '/^Secure Sockets Layer/,/^$/p'

Or just attach the PCAP file to your follow-up message.

--
        Viktor.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Michael Tuexen-4
In reply to this post by mahesh gs
> On 13. Apr 2017, at 11:11, mahesh gs <[hidden email]> 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
>
>
> <testcode.txt><proxy.cap>--
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
Hi,

We are using RHEL 7.0

Linux insvm02 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux


We built openssl code by enabling debug options and found that in TLS_ST_SR_CERT_VRFY state openssl checks  for the following conditions

1) If the datagram type is SCTP : : In this case it is DTLS and set to 1.

2) Value of s->renegotiate  : : in this case the value was set to 2. I guess this is set in post processing function of client hello.

3) If any sctp message is waiting to be received : : In this case this was true (1). When we debug inside the BIO_dgram_sctp_msg_waiting. We observed that the recvmsg system call returning the size (n = 14 bytes) that is exactly size of the next  package (Auth Change Cipher Spec) as shown in the below screenshot. 

So this function return "WORK_MORE_A" to the caller "read_state_machine" which intern returns SUB_STATE_ERROR. And this flow keeps repeating.
And also we observed that this issue is something to do with the timing of the messages received at SCTP layer. If the post processing message function executed before the next message arrives at SCTP layer, then the SSL negotiation is successful else SSL negotiation hangs at TLS_ST_SR_CERT_VEFY state.


Can someone who is familiar with the openssl code give us some insights about what is the logic behind the if check in TLS_ST_SR_CERT_VRFY state in post processing function ?

Inline image 1

Inline image 2



Inline image 3


Thanks,
Mahesh G S



On Wed, Apr 19, 2017 at 1:47 AM, Michael Tuexen <[hidden email]> wrote:
> On 13. Apr 2017, at 11:11, mahesh gs <[hidden email]> 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
>
>
> <testcode.txt><proxy.cap>--
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Matt Caswell-2
In reply to this post by Michael Tuexen-4
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 <[hidden email]> 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
>>
>>
>> <testcode.txt><proxy.cap>--
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Joseph Southwell
In reply to this post by Jason Schultz
Is there a way to enable one or both of those ciphers in OpenSSL?

On Apr 18, 2017, at 1:28 PM, Jason Schultz <[hidden email]> wrote:

RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Viktor Dukhovni
On Tue, Apr 18, 2017 at 05:06:40PM +0000, Viktor Dukhovni wrote:

> The ClientHello decodes via tshark as:
>
> [...]
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>                 Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
> [...]
>
> This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
> be broadly interoperable.  The DEFAULT cipherlist includes only
> AES, is there a chance that the server only supports RC4 and/or
> 3DES?
>
> Try:
>
>     $ openssl s_client -state -msg -cipher ALL \
>         -connect ftp.echannel.banksys.be:16370 -starttls ftp
>
> Capture a PCAP file of the traffic with
>
>     # tcpdump -s0 -w /some/file tcp port 16370
>
> and post the the decode from:
>
>     $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
>         sed -ne '/^Secure Sockets Layer/,/^$/p'
>
> Or just attach the PCAP file to your follow-up message.

On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote:

> Is there a way to enable one or both of those ciphers in OpenSSL?
>
> > On Apr 18, 2017, at 1:28 PM, Jason Schultz <[hidden email]> wrote:
> >
> > RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

With so many different names for the underlying TLS ciphersuites
one can only guess which ones are the same.  That said, I'd say
that the first one on your list is enabled by default, and was used
in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f).

It is possible that (despite any claims to the contrary) the server
only supports the 3DES ciphersuite above, in which case you need
either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure
option "--enable-weak-ssl-ciphers".   The 3DES TLS ciphers are by
default disabled at compile-time in OpenSSL 1.1.0 and later.

I did suggest the "-cipher ALL" option as a first place to start to
find out what the server actually supports.  I'm puzzled as to why
you've not tried that yet.

A more exotic scenario is that the server is configured with a weak
DHE group and having chosen DHE decides that the group is too weak.
In that case you could try just the purported AES cipher:

        -cipher "AES128-SHA"

The name was obtained via:

    $ openssl ciphers -V ALL | grep 0x00,0x2F
      0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

Finally, you really should ask for help from the server administrator
they should have useful data in their logs.

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