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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users