<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>I have not yet found the cause of
this issue, however I have <br>
found that a minimal version of your patch which just adds <br>
back the SSL_in_init() condition seems to at least make the <br>
diagnostic test case (using s_client) work again.</tt><tt><br>
<br>
I have not kept the test for s being NULL, as that case would <br>
have crashed a few lines earlier in SSL_shutdown(), so can't <br>
reach the if statement anyway.<br>
</tt><br>
<tt>I have attached the reduced patch, but I still think the real
<br>
cause must be elsewhere.</tt><br>
<br>
On 02/02/2016 12:34, Matt Caswell wrote:<br>
</div>
<blockquote class=" cite" id="mid_56B09432_40105_openssl_org"
cite="mid:56B09432.40105@openssl.org" type="cite">
<pre wrap="">On 02/02/16 11:24, Jakob Bohm wrote:
</pre>
<blockquote class=" cite" id="Cite_9997416" type="cite">
<pre wrap="">On 02/02/2016 11:40, Matt Caswell wrote:
</pre>
<blockquote class=" cite" id="Cite_1331733" type="cite">
<pre wrap="">On 02/02/16 07:52, Jakob Bohm wrote:
</pre>
<blockquote class=" cite" id="Cite_9826282" type="cite">
<pre wrap="">I am trying to upgrade an existing 3rd party multithreaded server
from OpenSSL 1.0.2c to 1.0.2f . However when I do so, it starts
mishandling the close_notify "alert".
1.0.2f seems to send the close_notify alert unencrypted followed
by an encrypted decrypt_failed alert, where 1.0.2c correctly
sends just an encrypted close_notify alert.
I am unsure if this exposed a bug in the daemon or in OpenSSL
itself.
</pre>
</blockquote>
<pre wrap="">I have a theory.
Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
middle of a handshake by ignoring it and returning 1 immediately
(meaning everything shutdown successfully). Clearly everything did not
shutdown successfully so the return value is not correct.
</pre>
</blockquote>
<pre wrap="">No, actual application data (just a few bytes) was sent in each
direction.
Specifically, some bytes were sent client to server, then a reply
was sent server to client and the connection was closed.
Also, the s_client output showed a completed handshake, with
ChangeCipherSpec in both directions and dump of certificate
chain before the first application data was sent (client to
server, then server to client).
The s_client command line was
cat data | openssl s_client -connect xx.xx.xx.xx:xxxx -msg -tls1
-ign_eof -debug
However I cannot rule out that the changes to either SSL_shutdown()
or the rearranged error checking code triggered the issue.
</pre>
</blockquote>
<pre wrap="">Hmmm. Perhaps try reverting the SSL_shutdown() change to rule that out
as related in some way? Patch attached to revert that change back to the
previous implementation.
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>