TLS DH handshake fails when Premaster secret contains leading zeros

Fixed, flighted Issue #9285068

Details

Author
Doug S.
Created
Oct 10, 2016
Privacy
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Fixed in build #
15002
Reports
Reported by 4 people

Sign in to watch or report this issue.

Steps to reproduce

A TLS handshake will sometimes fail when using a .NET 4.5 framework project using HttpWebRequest to initiate SChannel based TLS handshakes that establishes a DHE-RSA-AES256-SHA TLS session with my TLS server. I have confirmed that when the handshake fails the result of the Premaster secret value contains a leading zero octet, which must be stripped according to the https://tools.ietf.org/html/rfc5246#section-8.1.2
https://tools.ietf.org/html/rfc5246#section-8.1.2. This results in the bad mac error when client sends the finished message. I have confirmed that the Finished message decrypts properly if I leave the leading zero in the Premaster secret (pad the value to the modulus size of the DH group).

In theory we should see 1 out 256 SSL/TLS handshakes with DHE cipher suites fail (when the leading byte happens, by chance, to be zero), which is consistent with my experiments. I suspect that any ephemeral DH key exchange should have this problem.

I have reproduced this with is Windows 7 Ultimate. winver says "Microsoft Windows version 6.1 (Build 7601: Service pack 1)".

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Brad E.”

      Changed Assigned To to “Venkat K.”

      Changed Assigned To to “Andrei P.”

      Changed Status to “Won’t fix”

    • Is this something that MS is going to look further into? I noticed a won’t fix above the issue number and wonder exactly what that means…

    • Thank you for your feedback. At this time we do not plan on fixing this issue.

      At this time, we believe that this is a known issue in the Windows TLS stack and crypto libraries. There are no plans to fix this on Win7, but later OS versions have been serviced.

      If you get a repro on a more recent, fully patched OS (preferably, Windows 10), please activate the bug.

      Best regards,
      The Internet Explorer team

    • Microsoft Edge Team

      Changed Assigned To to “Andrei P.”

      Changed Status from “Won’t fix”

      Changed Status to “Won’t fix”

    • Thank you for your feedback. At this time we do not plan on fixing this issue.

      At this time, we believe that this is a known issue in the Windows TLS stack and crypto libraries. There are no plans to fix this on Win7, but later OS versions have been serviced.

      If you get a repro on a more recent, fully patched OS (preferably, Windows 10), please activate the bug.

      Best regards,
      The Internet Explorer team

    • This is a report about TLS protocol violation, in particular, ignoring the following explicit direction:

      Leading bytes of Z that contain all zero bits are 
      stripped before it is used as the pre_master_secret.
      

      (sec. 8.2.1 of RFC 5246)

      The possibility of this issue was alluded to in the similar DH padding issue that was fixed.

      Unfortunately, there is no easy workaround here. If a peer wants to interoperate with a defective implementation, the peer would be expected to run the TLS PRF with two inputs: one formatted per sec 8.2.1, and one incorrectly, and then determine by trial and error which path to use.

      On our end, we are prevented from fixing 3d party bugs in maintenance releases. We have no choice than to note to our dissatisfied customers that the root cause of interoperability failure is a defect in Microsoft products.

      It would be nice if Microsoft provided a fix along the lines specified above, but I understand the unwillingness to deal with this additional complexity.

      Thank you.

    • Microsoft Edge Team

      Changed Assigned To to “Andrei P.”

      Changed Status from “Won’t fix”

    • Thanks for the clarification; my assumption was that this was another report of the DH public share padding issue, which we’re not fixing on Win7.

      Will investigate and provide an update.

    • I would also like to add that we are seeing this issue with Outlook 2007, 2010,2013, and 2016 connecting to an on prem exchange 2013 environment. I noticed that the “found in” section was listing IE and the issue that started this tread was from Exchange connectivity.

      It might be better to have someone from the Exchange team look into this rather than the Internet Explorer team.

    • An issue in the Windows TLS stack would affect all applications using the Windows TLS stack, including IE, Edge, Outlook, SQL server, .NET apps, etc., and the possible fix would apply to all these apps as well.

    • Andrei P, thank you for the update and clarification. Please keep us posted on the progress and any potential fix information.

    • Microsoft Edge Team

      Changed Status to “Fixed, not yet flighted”

      Changed Title from “TLS DH handshake fails when Premaster secret contains leading zeros” to “TLS DH handshake fails when Premaster secret contains leading zeros”

    • This is showing as fixed now, can someone explain what the fix was and or how it maybe implemented? The issue appears to have started (for me at least) with KB 3161608 and 3172605. If there a new patch that fixes / reverses the issue? Do we have to uninstall the previous ones or does it just fix the problem? This is assuming its a KB fix…

    • Microsoft Edge Team

      Changed Status from “Fixed, not yet flighted” to “Fixed, flighted”

    • Anyone have any details here on what the fix is?

    • Hello,

      Thank you for providing this information about the issue. We are pleased to report this feature is fixed in Edge 15063 and is available in our latest Insider Preview build.

      Best Wishes,
      The MS Edge Team

    You need to sign in to your Microsoft account to add a comment.

    Sign in