Re: SSL_shutdown return error when close in init

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Linsell, StevenX
On Tue, 18 Apr 2017, [hidden email] wrote:

>Hello
> I'm using open1.1.0e in async mode with intel QuickAssist Engine to handle https connections? but there's some problem.
>
>client(ab)-------------------------- server(my program)
>
><---------TCP handshake----------------> -------------ssl client hello---------------> <---------server hello,certicate...--------- -----------client key exchange....--------> >//here, server's SSL_do_handshake reutrns SSL_ERROR_WANT_ASYNC repeatly,
>
>-----------FIN+ACK---------------------->
>
>//client want to close the connection, then, server should close ssl connection ,In program, I intend to close SSL connections in quiet mode?
>SSL_set_quiet_shutdown(ssl,1);
>SSL_shutdown(ssl);
>
>but SSL_shutdown returns SSL_ERROR_SSL, because SSL_in_init(s) return true.
>
>I'm confused, what should I do here ???
>(1) just call SSL_free(ssl) to free SSL connection, then the async engine may callback and using SSL's waitctx, which cause crash.  Also I noticed that SSL's job >doesn't free neither, which may cause memory leak;
>
>(2)continue call SSL_shutdown(ssl),  and it will always return SSL_ERROR_SSL
>
>Is anybody know? thanks  

The root cause of the issue is that it is not valid to move state from init to shutdown when there is still an asynchronous operation in progress.
The fact that the client wants to close the connection should be saved, the asynchronous operation should be completed (keep calling SSL_do_handshake until SSL_get_error does not return SSL_ERROR_WANT_ASYNC) then based on what you saved do the same behaviour you would have done in the case of the client wanting to close the connection if you are running synchronously.
As long as you have completed the asynchronous operation then there will be no problem calling SSL_free on the connection as there will be no callback that will run later.
By continuing to call SSL_do_handshake until the sync job completes all you are doing is running the SSL_do_handshake to the same point it would have returned and detected the error if you were running synchronously.
Note that it is never valid to call SSL_do_handshake(), start an asynchronous operation (SSL_get_error returning SSL_ERROR_WANT_ASYNC), then transition straight to calling a different asynchronous enabled function like SSL_shutdown(). If you do that you will find that when you call SSL_shutdown it will detect there is already an async job in progress and will context switch into that job rather than starting an async job for the SSL_shutdown behaviour. In other words you will end up running SSL_do_handshake code when you think you are running SSL_shutdown code. Even worse they may have completely different return behaviour so you get an unexpected result. 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.

Hope that helps,

Steve Linsell                                     Intel Shannon DCG/CID Software Development Team
[hidden email]

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

OpenSSL - User mailing list

> 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?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Jakob Bohm-7
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?
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.

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
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Linsell, StevenX
In reply to this post by Linsell, StevenX
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.

 
Steve Linsell                         Intel Shannon DCG/CID Software Development Team
[hidden email]

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Jakob Bohm-7
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
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Linsell, StevenX
In reply to this post by 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
[hidden email]

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_shutdown return error when close in init

Jakob Bohm-7
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