AsyncHandshakeCallback currently assumes that an SSL_ERROR_WANT_READ result from ProcessHandshake means it's our turn to write data from the write_bio. This isn't always the case - sometimes there's more data for us to read from the network, and if we blindly try to do a write operation we can end up entering InternalBeginWrite with write_bio.BytesPending == 0 (which will cause the original AuthenticateAsClient caller thread to hang inside of EndAuthenticateAsClient/EndRead indefinitely).

Instead this callback should check write_bio.BytesPending > 0 and initiate either a read or a write depending on which makes sense. I've attached a test that will verify this by presenting a server certificate which is larger than 16384 bytes (the size of the network buffer). This will force the server to split the handshake message into multiple writes, and if the client isn't prepared to perform multiple network reads in sequence then it will deadlock.

The following sample code will also provide a quick proof of concept, since slashdot's certificate is enormous (tried on a couple machines, YMMV 😄)

TcpClient tcp = new TcpClient();tcp.Connect("slashdot.org", 443);OpenSSL.SSL.SslStream ssl = new OpenSSL.SSL.SslStream(tcp.GetStream());ssl.AuthenticateAsClient("localhost");Console.WriteLine("Done");Console.ReadLine();

without patch: will hang inside AuthenticateAsClient
with patch: will complete as expected