Re: SSL_shutdown return error when close in init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux