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

[Jakob Bohm]

On 21/04/2017 01:35, Linsell, StevenX wrote:
> On 20/04/2017, Bohn, Jakob  wrote:
>> 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.
> So am I correct in thinking you are asking for an 'abort' mechanism for
> the async job? Effectively you would set a flag on the async job,
> then call the SSL_do_handshake again, and when it switched back into
> the async job (fibre) it would detect it was being aborted and return
> up the stack with a failure. You do still need to call the SSL_do_handshake
> that one time so that the fibre can run to completion and everything
> gets tidied up correctly though.
Even simpler: Just abort at the protocol level (not deep inside crypto) 
when
the next protocol level processing is about to be done anyway, making 
most of
the logic a simple reuse of what would happen if the other end sent a
malformed or otherwise unacceptable handshake record.

So if crypto is busy calculating DH shared secrets and deriving keys, it 
would
just continue doing so (asynchronously), then when the result is about 
to be
used at the protocol level, the protocol sees and executes the abort flag.

Similarly if the protocol is waiting for a handshake record from the 
other end,
it would continue that wait, then abort just before processing either a 
received
handshake or a protocol error (such as lost connection).

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