I'm testing a spoofing MITM SSL proxy based on boost::asio and boost::asio::stream::ssl, using boost 1.55 I register the tlsext_servername_callback, so that I can observe the called name during SSL handshake with the client. In the callback, I have the information needed to either get/create an appropriate SSL_CTX with certificates to use with the client, or start an SSL handshake with the server, to obtain the server certificate for re-signing and then put that back into the SSL_CTX to be passed to the client, before returning the tlsext_servername callback. It is clear that I must block the tlsext_servername callback from returning until I have the new SSL_CTX ready, which could take some time if I need to wait on a handshake with the real server. I can block return by performing a blocking handshake with the server, but then I consume one of the io_service threads merely blocking, and I don't want to waste them like that. I can successfully run it all as a new thread using blocking IO, in this form: ssl_connect(...) { boost::thread([...]() ({ sni_callback = [...](std::string server_name) { server.handshake(...); SSL_set_SSL_CTX(client.native_handle(), server.ctx)); }; client_socket.handshake(...); handler(); // really done by io_service.post }).detach(); } But I want to use stackful coroutines in the belief that thay are less costly and that I will be able to have more connections in progress (though I may have to link with BoringSSL). Using a coroutine spawn, I can convert the handshake with the server, like this: ssl_connect(...) { boost::asio::spawn(my_strand, [...](boost::asio::yield_context yield) { sni_callback = [...](std::string server_name) { server.async_handshake(..., yield[ec]); // <---- works nicely SSL_set_SSL_CTX(client.native_handle(), server.ctx)); }; client_socket.handshake(...); handler(); // really done by io_service.post }); } but the handshake with the client must remain blocking, otherwise, with: client_socket.async_handshake(..., yield[ec]); I get segfaults in the coroutine with unhelpful stack traces, mentioning only some SSL cleanup functions. However if the client connection hangs, then the client handshake can still hang and block a worker thread. My guess is that if the handshake with the client is not blocking, the SNI callback does not occur on the coroutine, and so I cannot properly block the return and possibly the use of yield in the SNI callback is invalid. If there is a solution that doesn't involve patching either libssl or stream::ssl, it will involve some asio_invoke_handler hooks. However, for that to work, the coroutine would have to be activated, but not to complete the async_handshake call. Instead it would be activated to handle the handshake read completion, leading to the parsing, SNI callback & return, further handshake write, and yield back to the io_service. I don't know if the coroutine/strand implementation can even do that -- be activated for work and not for return. So my first question is: is it likely possible to make coroutine do this? Looking in boost source detail/io.hpp for case engine::want_input_and_retry I notice: next_layer_.async_read_some( boost::asio::buffer(core_.input_buffer_), BOOST_ASIO_MOVE_CAST(io_op)(*this)); which seems to make no attempt to use asio_hanlder_invoke to allow it to be hooked, so that might need fixing. What sort of asio_handler_invoke hook would cause the handler to be invoked on the coroutine? Could strand.dispatch() do it? If it would, I'm not sure how to write such a hook either to work with argument dependent lookup, or to invoke in the coroutine. Otherwise I may as well stick to starting a scope-limited thread, and using blocking handshake operations. But I like to know the limits... Samjam