[openssl-users] Query regarding DTLS handshake

[mahesh gs]

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

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

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

>
> Best regards
> Michael
>
>
>
> >
> >
> > I added some debug statements, below is the debug statements.
> >
> >
> > Debug statements when the handshake does not work
> >
> > <image.png>
> >
> > 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.png>
> >
> > 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
> >
> >
> > --
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170502/37de0d07/attachment.html>