Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to make https request when Oid lookup takes too long #21320
This issue was discovered in .NET 4.6, but would also affect .NET core apps running on windows.
Here is a link to the feedback I created on the connect website for this issue:
The solution is to use a different Oid constructor that prevents the potentially costly Oid friendly name lookup. What follows is a more detailed description of how issue we were seeing in our application.
I support a desktop application that calls a WCF service hosted on our servers over https. A small number of our clients with the desktop application installed (~20/10000) have been reporting issues connecting to the WCF service since installing KB4014511. The exception being thrown is:
System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
The error is misleading though. After quite a lot of troubleshooting, we were able to pinpoint the source of the problem. By decompiling the System.dll, I saw that the following 2 lines were added to the System.Net.Security.SecureChannel class shipped with KB4014511:
private readonly Oid m_ServerAuthOid = new Oid("18.104.22.168.22.214.171.124.1");
The initialization of those Oid objects is triggering a system call to the CryptFindOIDInfo function to lookup the friendly name associated with the specified OID. When the machine is part of a domain, that call will perform the lookup against active directory (see the Remarks in the docs https://msdn.microsoft.com/en-us/library/windows/desktop/aa379938%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396).
For our clients that are having issues connecting to our WCF service, this lookup is taking up to 15 seconds. Because these Oid lookups are happening after WCF has opened the TCP connection to our server, but before the SSL/TLS handshake has started, we are seeing the above error. So, the TCP connection is opened, 2 OID lookups happen taking up to 30 seconds, the application then attempts to start the SSL/TLS handshake, but by the time the SSL/TLS handshake is attempted, the TCP connection has already been reset by the server (in our case the server resets the connection after 10 seconds).
We need to make the equivalent change here as well:
@primarilysoftware Thank you for your work on this PR and also for your analysis of the problem itself. We would like to get this PR completed as soon as possible. We are also investigating the same issues on .NET Framework that you reported via Connect portal.
After several discussion with the crypto API experts @bartonjs, we have concluded that it would be best to further simplify this PR. Instead of using the CRYPT_OID_DISABLE_SEARCH_DS_FLAG etc., please just use the two string parameter
private readonly Oid _serverAuthOid = new Oid("126.96.36.199.188.8.131.52.1", "184.108.40.206.220.127.116.11.1"); private readonly Oid _clientAuthOid = new Oid("18.104.22.168.22.214.171.124.2", "126.96.36.199.188.8.131.52.2");
Using the dotted number notation for the friendly name should avoid any Oid lookups and also not require any localization with the name.
Can you please revise your PR? And if possible, please test out the changes in your environment as well to assist overall test coverage of this change. Thanks!
Thanks for making the changes to the PR. At this point, we are going to merge this PR. Please continue your testing on your client's machines.
Jul 4, 2017
11 checks passed
@primarilysoftware I assume by ".NET release or patch", you are referring to .NET Framework and not .NET Core? We are actively looking into this to determine the earliest possible time to issue such a servicing release.
Historically, .NET Framework releases servicing fixes approximately monthly. But there is a lead time to getting a fix into any release train. We will communicate schedule expectations via the Connect portal and not this PR. This PR is now merged into master branch and is considered closed.
Please follow the Connect portal bug you opened up about .NET Framework for status updates on servicing releases. Thanks.