none
Connection Reset Before SSL/TLS Handshake Completes RRS feed

  • Question

  • I support a Desktop Application that calls back to a WCF service over SSL/TLS.  Of the 10,000 or so clients we have with the Desktop app installed, 20 or so started reporting issues connecting to the WCF service after installing KB4014511.  The error being reported 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

    Running Wireshark on the machine, we see that after opening the TCP connection with the server, the SSL/TLS handshake never starts, and after 10 seconds the server resets the connection:

    [Screenshot omitted because account has not been verified]

    The exception however is thrown approximately 30 seconds after the WCF call is initiated.  After 30 seconds, it is true that the server did reset the connection, but the strange part is why is there a 30 second pause before beginning the SSL/TLS handshake?

    Using API Monitor, we were able to find that the source of the delay is 2 calls to CryptFindOIDInfo.  It looks like these calls are being made to get the friendly name for 1.3.6.1.5.5.7.3.1 (Service Certificate) and 1.3.6.1.5.5.7.3.2 (Client Certificate).  This lines up pretty well with the change described in KB4014511.

    Now only 20 or so of our 10,000+ installations are being impacted by this issue.  The ones that are impacted have been part of a network with a domain controller.  The docs for CryptFindOIDInfo do indicate that "The CryptFindOIDInfo function performs a lookup in the active directory to retrieve the friendly names of OIDs under the following conditions...".  Reviewing the Wireshark trace again I noticed the following SMB_NETLOGON requests between opening the TCP connection and the connection reset:

    [Screenshot omitted because account has not been verified]

    So for this particular machine, it is having trouble authenticating with the domain controller.  I am assuming this authentication attempt is a precursor to the AD lookup of the OID.  It would appear that there is something wrong with the network configuration on these machines that are have having trouble making WCF calls.  Nonetheless, this problem only appeared after KB4014511 was installed on the machines.  I reviewed the decompiled code for System.Net.Security.SecureChannel class that was updated in the patch, and found 2 new fields had been added, m_ServerAuthOid and m_ClientAuthOid:

    [Screenshot omitted because account has not been verified]

    These fields are initialized as part of the class initialization, which triggers the Oid lookups.

    This creates a big problem for our software, in that code that once worked, no longer works because of a Windows patch, and there is no workaround that I can see short of removing the security patch from the clients' machines.  I do not want to be in the business of uninstalling security patches, so is there any other workaround that we could use?

    Tuesday, June 20, 2017 10:29 PM

All replies

  • Hi cinjguy,

    For certificate over SSL, is the EKU specified?

    Per to this KB4014511, your certificate should have EKU.

    If you temporarily can’t access correctly reissued certificates, you can choose to opt in or out of the security change across all computer operations to avoid any connectivity effects.

    I would suggest you refer below link for more information.

    # Description of the Security and Quality Rollup for the .NET Framework 4.6 and 4.6.1 for Windows 7 SP1 and Windows Server 2008 R2 SP1 and the .NET Framework 4.6 for Windows Server 2008 SP2: May 9, 2017

    https://support.microsoft.com/en-us/help/4014511/description-of-the-security-and-quality-rollup-for-the-net-framework-4

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, June 21, 2017 2:07 AM
  • Yes the EKU is specified.  This really doesn't have anything to do with validating the EKU extension of the cert.  The issue is occurring before the SSL/TLS handshake starts.  It is taking ~30 seconds for the SecureChannel class to initialize because of these OID lookups that were added in KB4014511.  By the time the SecureChannel class has been initialized to begin the SSL/TLS handshake, the TCP connection has already been closed.
    Wednesday, June 21, 2017 12:19 PM
  • Hi cinjguy,

    Will it work if you opt out of the security change by modifying the registry?

    Did this issue only exist on the computer with KB4014511 and all the computers with KB 4014511 will get this error? If it does, I would suggest you share us a simple demo, system environment and detailed steps, then we will try to create such environment to try to reproduce your issue.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 22, 2017 1:57 AM
  • Hi,

    I am unable to see your screenshots, but I am assuming that this problem is related to crypto weak algorithm  protection. My guess is that the server certificate uses an algorithm that is deemed weak/ invalid usage by the clients with the patch applied, and hence the client closes the connection. 

    For details see

    https://technet.microsoft.com/en-us/library/dn375961(v=ws.11).aspx - Protecting Against Weak Cryptographic Algorithms .You might be able to turn on logging  (one way to do this documented in the link above) to see what is actually causing this connection to be aborted

    https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/map-object-identifiers-to-cryptography-algorithms - Mapping Object Identifiers to Cryptography Algorithms


    • Edited by lanax Thursday, June 22, 2017 6:35 AM
    Thursday, June 22, 2017 5:46 AM
  • We tried the various options to opt out of this security update outlined in the KB, but none of them fixed the issue we were seeing.  This is because the problem is not with applying the new security policy, it is related to some new initialization code that was added to the SecureChannel class.  This new initialization code is the source of the problem.  The app never gets to the point where the new security policy would be applied.

    Reproduction is tricky because it depends on the machine being part of a domain, where the call to CryptFindOIDInfo issues the lookup against the domain controller, and the lookup takes too long.  Assuming you have such an environment in place, you can reproduce the issue with the following powershell:

     New-Object System.Security.Cryptography.Oid("1.3.6.1.5.5.7.3.1")

    Thursday, June 22, 2017 2:19 PM
  • That was our first thought as we investigated this issue, but as we dug deeper, we found that we were never even getting to the point of certificate verification.  The delay is occurring after the TCP connection is opened, but before the SSL/TLS handshake, so we are at a point where we have not even received a certificate to verify.
    Thursday, June 22, 2017 2:25 PM
  • Hi cinjguy,  

    Thank you for posting in the MSDN Forum.

    I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.

    Sorry for any inconvenience and have a nice day!

    Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, June 26, 2017 7:24 AM
  • Thanks for the update.  I have also created feedback on the connect website for this issue:

    https://connect.microsoft.com/VisualStudio/feedback/details/3136313/unable-to-make-wcf-calls-after-kb4014511-from-certain-clients

    And submitted a pull request to the dotnet/corefx repo:

    https://github.com/dotnet/corefx/pull/21320

    Monday, June 26, 2017 2:05 PM
  • Hi cinjguy,

    Thanks a lot for sharing the information.

    I would suggest you mark your reply as answer, and then others who run into the same issue would find your solution easily.

    Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Tuesday, June 27, 2017 2:14 AM
  • I am not sure that I have an answer at this point, maybe you could clarify something for me.  If a PR is accepted into .NET core, would it be ported into the full framework as well?  If so, what kind of timeline is there for getting that released?

    As is, our code is still broken on these machines, and there is very little we can do about it until the bug is addressed in the full .NET framework.

    Tuesday, June 27, 2017 5:43 PM
  • Hi cinjguy,

    Welcome back.

    I am afraid I could not help you lift doubts. For the PR scope and timeline depends on Microsoft Net framework Team, there is no way for me to contact them.

    I think you could keep pay attention on the Git issue.

    It would be appreciated if you could share us the latest news when you get anything new on this issue.

    Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 29, 2017 8:10 AM
  • Any progress update for getting this issue resolved and released?
    Wednesday, September 6, 2017 2:20 PM