SslStream.AuthenticateAsServer 挂起

Question

Using VS 10 with .NET framework 4.0, I have written three c# unit tests to check the SslStream behaviour for different server / client protocol settings.

  private void InternalTestSsl(SslProtocols serverProtocols, SslProtocols clientProtocols)
  {
     X509Certificate2 certificate = RetrieveServerCertificate();
     var server = new TcpListener(new IPEndPoint(IPAddress.Any, 20000));
     server.Start();
     try
     {
        // create and execute a task for server operations
        var serverTask = new Task(() =>
        {
           TcpClient connectionToClient = server.AcceptTcpClient();
           var sslStream = new SslStream(connectionToClient.GetStream(), false, (a, b, c, d) => true, (a, b, c, d, e) => certificate);
           sslStream.AuthenticateAsServer(certificate, false, serverProtocols, true);
           Assert.IsTrue(sslStream.IsAuthenticated);
        });
        serverTask.Start();

        // create and execute a task for client operations
        var clientTask = new Task(() =>
        {
           var clientConnection = new TcpClient();
           clientConnection.Connect(new IPEndPoint(IPAddress.Loopback, 20000));
           var sslStream = new SslStream(clientConnection.GetStream(), false, (a, b, c, d) => true, (a, b, c, d, e) => null);
           sslStream.AuthenticateAsClient(Environment.MachineName, null, clientProtocols, true);
           Assert.IsTrue(sslStream.IsAuthenticated);
        });
        clientTask.Start();

        // wait for both server and client task to finish, check results
        if (!serverTask.Wait(TimeSpan.FromSeconds(1)))
        {
           throw new Exception("Server task did not end in time.");
        }
        if (!clientTask.Wait(TimeSpan.FromSeconds(1)))
        {
           throw new Exception("Client task did not end in time.");
        }
     }
     finally
     {
        server.Stop();
     }
  }

  [TestMethod]
  public void TestTlsTls()
  {
     InternalTestSsl(SslProtocols.Tls, SslProtocols.Tls);
  }

  [TestMethod]
  public void TestTlsSsl3()
  {
     InternalTestSsl(SslProtocols.Tls, SslProtocols.Ssl3);
  }

  [TestMethod]
  public void TestSsl3Tls()
  {
     InternalTestSsl(SslProtocols.Ssl3, SslProtocols.Tls);
  }

TestTlsTls passes as both server and client define the same protocols to be used (only TLS). The failure of TestTlsSsl3 is also completely understandable (an AuthenticationException is thrown because the server wants TLS to be used, but the client want´s to solely play SSL3).

I expected the test "TestSsl3Tls" to fail with the same AuthenticationException, but instead, my custom exception "Server task did not end in time." was fired. When debugging, I see that only the client task receives an AuthenticationException while the serverTask remains in the call of AuthenticateAsServer. Swapping my Wait commands results in the opposite: AuthenticationException for "TestSsl3Tls", "Client did not end in time" for "TestTlsSsl3".

Is that the normal behaviour, the AuthenticationException only being thrown on one side, the other side waiting (may be for a new authentication attempt or a disconnect)?

Answer 1

I dont know the answer to your question whether this behaviour is normal, but in my opinion this is a bug and I recently had the same issue and since I could not control the client security protocol, my server ended up freezing all the time.

I solved it by Disposing the sslstream, which causes an Exception in the AuthenticateAsServer and thus allowed my server to continue.

here is the code fragment

    // wait for both server and client task to finish, check results
    if (!serverTask.Wait(TimeSpan.FromSeconds(1)))
    {
       sslStream.Dispose(); // this line will cause an exception in the server task (AuthenticateAsServer), which allows the server to continue ...
    }

Since your question led me to the root of my freezing issue, I though I will share my solution ...

Answer 2

Try:

socket.ReceiveTimeout = //some timeout in millis

I ran into this same issue, but the proposed dispose solution didn't work in my case. My use case was a little different. I get a Socket from an async Begin/EndAcceptSocket off a TcpListener. When I called AuthenticateAsServer with a client that had a protocol mismatch, it would never return, and disposing the stream didn't make it return either.

What I found is that I had to set the socket.ReceiveTimeout as shown below.

IAsyncResult asyncResult;//passed from BeginAcceptSocket callback
TcpListener listener = (TcpListener)asyncResult.AsyncState;
var socket = listener.EndAcceptSocket(asyncResult);
int timeoutInMillis;//set to whatever makes sense for your use case.

socket.ReceiveTimeout = timeoutInMillis; // This line fixed it for me

var stream = new SslStream(new NetworkStream(socket));
stream.AuthenticateAsServer(...); // This line doesn't hang any longer than the timeout.

Setting the receive timeout on the socket made sure that the AuthenticateAsServer call returned after the timeout instead of hanging forever in the case of a protocol mismatch. It may not be applicable in all scenarios, but in my case, I was never sending so much data that it should take longer than a few seconds.

In all typical connect scenarios, it will just authenticate and I don't need the timeout, but it eliminated the edge case where it could hang forever.