[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: [openssl-users] SSL_shutdown return error when close in init
From:       Jakob Bohm <jb-openssl () wisemo ! com>
Date:       2017-04-21 8:39:15
Message-ID: 20ac7ec4-00f5-a204-282c-0ebfc6a03ee4 () wisemo ! com
[Download RAW message or body]

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_handsha=
ke
> 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=F8borg, 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

-- =

openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[prev in list] [next in list] [prev in thread] [next in thread]