On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
> On 20. Apr 2017, at 20:01, mahesh gs <mahesh116@xxxxxxxxx> 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@xxxxxxxxxxx> 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
