Re: [openssl-users] SSL_shutdown return error when close in init
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
Re: [openssl-users] SSL_shutdown return error when close in init
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.lins...@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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
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
Re: [openssl-users] SSL_shutdown return error when close in init
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 stevenx.lins...@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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
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
Re: [openssl-users] SSL_shutdown return error when close in init
> 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
Re: [openssl-users] SSL_shutdown return error when close in init
On Tue, 18 Apr 2017, mid...@163.com 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 stevenx.lins...@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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL_shutdown return error when close in init state(openssl 1.1.0)
Hello
I'm using open1.1.0e in async mode with intel QuickAssist Engine to handle
https connections， but there's some problem.
I use apache benchmark tool to test thehttps connections, the description is
as follow：
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.
int SSL_shutdown(SSL *s)
{
/*
* Note that this function behaves differently from what one might
* expect. Return values are 0 for no success (yet), 1 for success; but
* calling it once is usually not enough, even if blocking I/O is used
* (see ssl3_shutdown).
*/
if (s->handshake_func == NULL) {
SSLerr(SSL_F_SSL_SHUTDOWN, SSL_R_UNINITIALIZED);
return -1;
}
if (!SSL_in_init(s)) {
if ((s->mode & SSL_MODE_ASYNC) && ASYNC_get_current_job() == NULL) {
struct ssl_async_args args;
args.s = s;
args.type = OTHERFUNC;
args.f.func_other = s->method->ssl_shutdown;
return ssl_start_async_job(s, , ssl_io_intern);
} else {
return s->method->ssl_shutdown(s);
}
} else {
SSLerr(SSL_F_SSL_SHUTDOWN, SSL_R_SHUTDOWN_WHILE_IN_INIT);
return -1;
}
}
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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
