[openssl-users] Query regarding DTLS handshake

[mahesh gs]

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.


I added some debug statements, below is the debug statements.


*Debug statements when the handshake does not work*

[image: Inline image 1]

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*

[image: Inline image 3]

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.brejcha at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170420/0353784e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 60011 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170420/0353784e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 46882 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170420/0353784e/attachment-0003.png>