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@xxxxxxxxx -------------------------------------------------------------- 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
