On 05/02/16 04:25, Jakob Bohm wrote:
> I have not yet found the cause of this issue, however I have
> found that a minimal version of your patch which just adds
> back the SSL_in_init() condition seems to at least make the
> diagnostic test case (using s_client) work again.
>
> I have not kept t
I have not yet found the cause of this issue, however I have
found that a minimal version of your patch which just adds
back the SSL_in_init() condition seems to at least make the
diagnostic test case (using s_client) work again.
I have not kept the test for s being NULL, as that case would
have
On 02/02/16 11:24, Jakob Bohm wrote:
> On 02/02/2016 11:40, Matt Caswell wrote:
>> On 02/02/16 07:52, Jakob Bohm wrote:
>>> 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 "aler
On 02/02/2016 11:40, Matt Caswell wrote:
On 02/02/16 07:52, Jakob Bohm wrote:
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 unen
On 02/02/16 07:52, Jakob Bohm wrote:
> 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 encrypt
