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