<div dir="ltr">Hi,<div><br></div><div>We were able to further localize this problem and found the problem is with the function "BIO_dgram_sctp_wait_for_dry". In this function after enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to peek to the message at SCTP layer, in this case the size of the message waiting in the lower layer is 15 which size is exactly the size of "Handshake Alert" that is received from the server and waiting to be read. Dry event is never read from the lower layer that causes the SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application.</div><div><br></div><div>Current version of openssl we are using is 01.01.00g.<br></div><div><br></div><div>We have tested and able to reproduce this issue with the OPENSSL 01.00.02k version that is packaged with RHEL 7.4 as well.</div><div><br><div><br></div><div>Thanks,</div><div>Mahesh G S</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <span dir="ltr"><<a href="mailto:mahesh116@gmail.com" target="_blank">mahesh116@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Matt,<div><br></div><div>Thanks for the response.</div><div><br></div><div>We debugged through openssl code to get to know the reason why client is not reading "SSL Alert".</div><div><br></div><div>Once the "ClientKeyExchange" is sent openssl trying to send out the "ChangeCipherSpec"  message which is creating the problem. </div><div><br></div><div>The pre-work function for "ChangeCipherSpec" enables SCTP dry event and wait for dry event notification.<br></div><div><br></div><div><img src="cid:ii_15fd919d829991b8" alt="Inline image 1" width="450" height="562"><br></div><div><br></div><div><br></div><div>In this scenario, dry notification is never sent from SCTP. "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never enters "read_state_machine" where alert is to be red.This causes SSL_Connect to be in infinite loop.</div><div><br></div><div><br></div><div>Thanks,<br></div><div>Mahesh G S</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 17/11/17 06:42, mahesh gs wrote:<br>
>  Why<br>
> does client respond with "Client key exchange" even if the the handshake<br>
> failure alert is sent from server?<br>
<br>
</span>The client will send its entire flight of messages before it attempts to<br>
read anything from the server. So, in this case, the ClientKeyExchange<br>
message is still sent because the client hasn't read the alert yet.<br>
<div class="m_-7368320651688202513HOEnZb"><div class="m_-7368320651688202513h5"><br>
Matt<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/mailma<wbr>n/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>