Timeout: BeginAuthenticateAsClient vs AuthenticateAsClient

Question

I'm developing a .NET service which tries to establish a secure connection to a server. The service does not know in advance if the server supports secure connections. That's why I simply try to establish a secure connection and if that fails I'll fallback to the unsecure connection.

I'm using TcpClient together with SslStream:

tcpClient.BeginConnect(hostname, port, Start, null);

private void Start(IAsyncResult asyncResult)
{
  X509CertificateCollection certCollection = new X509CertificateCollection();
  certCollection.Add(new X509Certificate2("cert.p12", "pw"));

  SslStream sslStream = new SslStream(tcpClient.GetStream(), false, new RemoteCertificateValidationCallback(ValidateCertificate));

  sslStream.ReadTimeout = 2000;

  sslStream.BeginAuthenticateAsClient("name", certCollection, SslProtocols.Tls, false, AuthenticateCallback, sslStream);
}

private void AuthenticateCallback(IAsyncResult asyncResult)
{
stream.ReadTimeout = -1;

// secure connection has been established
}

In the case that the server does not support the requested encryption it takes 2 minutes before the callback method is being called. Using the synchronous method AuthenticateAsClient() instead takes only the expected 2 seconds (as requested by setting the ReadTimeout):

sslStream.AuthenticateAsClient("ESLD Server", certCollection, SslProtocols.Tls, false);

Why does the timeout only apply to the synchronous method? How can I reduce the callback time for the asynchronous method? Or is there a better approach for checking if the server supports secure connections?

score 0 · Answer 1 · answered Mar 23 '15 at 15:20

I can't give a definitive answer, just expand on a few problems I experienced in relation to this.

What OS are (were) you trying this on?

What I found is that mutual authentication, if the client side connection is being set up through asynchronous calls (BeginXxxx with callbacks), works perfectly on Windows XP, but I can't get it to work on Windows 7 or later. The synchronous methods work fine in XP through 8.1, but asynchronous gives the strangest results on all except XP.

In Windows 7, it is as if the certificate(s) you pass in BeginAuthenticateAsClient never make it to the other side. The remote certificate validation callback set up by the SslStream constructor gets Null for the certificate and chain parameters, and RemoteCertificateNotAvailable for the SslPolicyErrors parameter. Use AuthenticateAsClient instead of [BeginAuthenticateAsClient + callback], and the problem goes away.

In Windows 8.1, it was even stranger: when I ran the exact same code there, the callback to BeginAuthenticateAsClient was called, signaling completion of the authentication process, before the remote certificate authentication callback set up by the SslStream constructor was called at the remote side, so the server application hadn't had a chance to either accept or reject the client certificate yet.

I was using Windows 7. I ended up using AuthenticateAsClient(). — sqeez3r, Apr 09 '15 at 09:46
AuthenticateAsClient is not an option in my case, I'm rewriting existing code that did it that way to get rid of the thread-per-connection approach synchronous calls make necessary. — Luc VdV, Apr 10 '15 at 10:08
And BTW, I did find the problem: it only happens when you use your own CA key to sign certificates. Delete the registry key where all CA certificates are stored (don't remember its path by heart, but this should get you started in the right direction). The key is repopulated automatically, and your own CA works from that moment on. — Luc VdV, Apr 10 '15 at 10:14

Timeout: BeginAuthenticateAsClient vs AuthenticateAsClient

1 Answers1