Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

> On 2. May 2017, at 08:03, mahesh gs  wrote:
> 
> 
> 
> On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen 
>  wrote:
> > On 20. Apr 2017, at 20:01, mahesh gs  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.
OK, I see. It isn't fixed in our case. That is why I sent the patch.
Thanks for the feedback.

Best regards
Michael
> 
> 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 
> >  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

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

[Michael Tuexen]

> On 20. Apr 2017, at 20:01, mahesh gs  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?

Best regards
Michael



dtls.patch
Description: Binary data

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

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

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



> 
> 


0xB42AB632.asc
Description: application/pgp-keys


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

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

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




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

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

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.

Martin


>>
>>
>> Thanks,
>> Mahesh G S 
>>
>> On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell > > 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 > > 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
>> 
>>
>>
>>
>>


0xB42AB632.asc
Description: application/pgp-keys


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

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

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

> 
> 
> Thanks,
> Mahesh G S 
> 
> On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell  > 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  > 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

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

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

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

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

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

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

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

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

Matt



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

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

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

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

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

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

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

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

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

M.


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


0xB42AB632.asc
Description: application/pgp-keys


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

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

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

Are you using blocking or unblocking I/O?

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

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

Re: [openssl-users] Query regarding DTLS handshake

[Matt Caswell]

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

Your trace shows the following interactions occurring:

Client Server
-- --

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

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

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

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

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

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

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