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

[Linsell, StevenX]

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.

I discussed doing this last year with Matt. At the time I couldn't justify
the change as I couldn't come up with a scenario where it didn't just
make sense to keep calling the function until the asynchronous operation
completed. The only scenario I did come up with was if the hardware
crypto device underneath stopped responding (so will never come back).
In that case having an abort mechanism allows the application to 
eventually time out, set the abort flag, make the function call and then 
cause the async job to fail and come back up the stack. 
We decided that if I wanted to pursue that abort functionality
I should implement it as an ENGINE message that would pass the 
ASYNC_WAIT_CTX of the connection. The engine would then need to
ensure the ASYNC_WAIT_CTX's custom field had a structure that 
included an abort flag. The engine could then keep self contained
the mechanism for setting the abort flag and dealing with checking
the flag when switching back into the async job (assuming we
are only pausing the job from within the engine).
I was going to implement a prototype that did that but it's something
that is still on my list of things to try out.

>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).

Actually I'd worry about the abort solution from a security stand point.
The trouble is if you are going to abort the connection down in the 
crypto layer then effectively you are creating a new failure path and
potentially changing behaviour seen at the client.
You'd need to be very careful down there to ensure you are not 
creating any kind of oracle that can be exploited.

The current behaviour of keep calling SSL_do_handshake and then fail
after the asynchronous operation completes will look exactly the same 
as the synchronous operation to the client on the other end. The only
difference being that the asynchronous connection will look like a 
particularly slow connection due to the latency introduced by the
asynchronous behavior (depending on server load). They both execute
 to the same point in the handshake before the failure can be dealt with.

I do agree it would be much nicer to minimize the logic changes
at the application level but I'm not convinced yet that an abort 
mechanism is the way to go.

Steve Linsell                   Intel Shannon DCG/CID Software Development Team
Stevenx.Linsell at intel.com

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.