<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <span dir="ltr"><<a href="mailto:Michael.Tuexen@lurchi.franken.de" target="_blank">Michael.Tuexen@lurchi.franken.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On 20. Apr 2017, at 20:01, mahesh gs <<a href="mailto:mahesh116@gmail.com">mahesh116@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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.<br>
><br>
> 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.<br>
</span>Can you try the attached patch and report if it fixes the issue for you?<br></blockquote><div><br></div><div>    I have tried with the patch provided by Matt. Our test results are successful. Issue is fixed with the patch.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888">Michael<br>
<br>
</font></span><br><br>
><br>
><br>
> I added some debug statements, below is the debug statements.<br>
><br>
><br>
> Debug statements when the handshake does not work<br>
><br>
> <image.png><br>
><br>
> Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  in - <a href="https://github.com/openssl/openssl/issues/3251" rel="noreferrer" target="_blank">https://github.com/openssl/<wbr>openssl/issues/3251</a><br>
><br>
> Debug logs when the handshake is successful<br>
><br>
> <image.png><br>
><br>
> 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.<br>
><br>
><br>
> Thanks,<br>
> Mahesh G S<br>
><br>
> On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <<a href="mailto:martin.brejcha@mavenir.com">martin.brejcha@mavenir.com</a>> wrote:<br>
><br>
><br>
> Matt Caswell wrote on 04/20/2017 03:23 PM:<br>
> ><br>
> ><br>
> > On 20/04/17 14:19, Martin Brejcha wrote:<br>
> >><br>
> >><br>
> >> Matt Caswell wrote on 04/20/2017 01:29 PM:<br>
> >>><br>
> >>><br>
> >>> On 20/04/17 12:26, mahesh gs wrote:<br>
> >>>> Hi Matt,<br>
> >>>><br>
> >>>> Yes I raised github case for the same issue. I also tried running this<br>
> >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and<br>
> >>>> handshake is successful with the latest SNAPSHOT code which is not an<br>
> >>>> official release.<br>
> >>>><br>
> >>>> I checked the github repo history and observer that during commits on<br>
> >>>> (11 th Jan) as a part of "Move state machine knowledge out of the record<br>
> >>>> layer".  "renegotiate" bit that is set to "2" in function<br>
> >>>> "tls_post_process_client_<wbr>hello" has been removed. May be that is causing<br>
> >>>> the call flow to be successful in the latest SNAPSHOT release.<br>
> >>>><br>
> >>>> I am assuming commits that are done on 11th Jan or later are not part of<br>
> >>>> release openssl 01.01.00e<br>
> >>><br>
> >>> Ah. No. That commit is in the dev branch only (scheduled for version<br>
> >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that<br>
> >>> commit might help things, but probably a different solution is more<br>
> >>> appropriate for 1.1.0.<br>
> >>><br>
> >>> I'm looking at this issue at the moment.<br>
> >>><br>
> >>> Matt<br>
> >>><br>
> >><br>
> >> hi,<br>
> >><br>
> >> btw: I've tested similar scenario and handshake works fine.<br>
> >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, non-blocking sockets and segmented certificate)<br>
> >> So, it should work also with 1.1.0e version.<br>
> ><br>
> > Thanks. Did your handshake include client auth? I think this issue only<br>
> > arises in that case.<br>
> ><br>
> > Matt<br>
> ><br>
> ><br>
><br>
> yes, client auth with segmented certificate has been included.<br>
><br>
> Martin<br>
><br>
><br>
><br>
> ><br>
> ><br>
><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
><br>
><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br>
<br>--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div></div>