[openssl-users] SSL_shutdown return error when close in init

[Jakob Bohm]

On 20/04/2017 13:16, Linsell, StevenX wrote:
> On 19/04/2017, Bohn, Jakob via openssl-users wrote:
>
>> On 19/04/2017 14:35, Salz, Rich via openssl-users wrote:
>>>> The OpenSSL documentation makes it clear that you must keep calling
>>>> the same asynchronous function with the same parameters until the
>>>> async job has completed.
>>> Is there a way we can (relatively cheaply) check for that type of
>>>   programming error and return an "in progress on another op" error?
> Yes, I raised a pull request for something similar here:
> https://github.com/openssl/openssl/pull/1736
> Unfortunately it is over 6 months old now and needs to be rebased and brought
> up to date with the latest master (my bad as I've not had time).
> If I get a moment I'll try and get it back up to date.
>
>> Also, for the shutdown case, it would be nice (in general) if attempting
>> shutdown during a handshake will make the handshake abort as soon as the
>> protocol allows, rather than going through all the remaining steps and their
>> transmissions.
>>
>> In other words, returning appropriate errors/alerts to the other end
>> according to the handshake step.
> The problem here is that you have a suspended fibre midway through the
> handshake operation. It may have allocated memory not just on the stack
> local to the fibre but dynamically on the heap. The fibre must be resumed
> to allow it to return up the stack and exit the fibre. When you are
> running asynchronously you are also by definition going to be running
> with non-blocking sockets. This means when you recall the
> SSL_do_handshake to resume the fibre you are only going to keep
> recalling it until the point it first comes back up the stack and exits the
> fibre. This will happen at the first point you try and do some non blocking
> I/O, i.e. send or receive during the handshake. At that point you will be
> in the same situation you are in if you were running synchronously with
> non blocking sockets (you may have detected the error earlier when
> running asynchronously but both asynchronous and synchronous
> only act on it at the same stage of the handshake).
> The pain point for the user is in having to remember the error has
> occurred and keep recalling the SSL_do_handshake until the
> async job (fibre) has completed.
Let me clarify: The idea was not to change the synchronization structure,
but to set a flag or otherwise (asynchronously or in a small critical
section) change the state such that when the communication async
operations resume, they will proceed directly to a failure state
skipping as much of the processing and transmission as possible.

For example if it was waiting for a "hello" from the other end,
when that "hello" arrives, it would not process the bytes in that
hello, but respond as if it received a bad hello (with
"aborted/closed" rather than "invalid hello" as the error/alert
code).  It would not proceed to e.g. validate incoming public keys,
send public keys, generate nonces, derive keys etc.

This serves two purposes: To make the "SSL_shutdown" call "just work"
from an application perspective, and to minimize security exposure
after the call has been made (e.g. in case some application level
code decides the other end is probably malicious).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
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