WS2016 AD upgrade problem: TLS ciphers

We’ve been replacing all our WS2012R2 DCs with WS2016 DCs. A non-Windows platform application which performs LDAPS queries against AD had a breaking issue. That application leverages a JDK library to establish the TLS connection (for LDAPS) with a domain controller.

See https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server for Microsoft details on the newly added crypto ciphers. An interesting detail is that the preferred crypto cipher for WS2016 is still in draft status! Presumably it was chosen because it is significantly faster than the other new/strong ciphers.

The exact details of the known problem are still a bit sketchy, so I can’t share that level of detail definitively. The facts are that both WS2016 server and JDK client have ciphers in common, but a mutually supported cipher is not negotiated (whereas a WS2012R2 server with the same JDK client does negotiate successfully). The JDK team has an issue tracking this which they have resolved based on wire-level examination showing that the WS2016 server doesn’t properly do TLS cipher negotiation: https://bugs.openjdk.java.net/browse/JDK-8178429.

So we looked to find a solution. We are aware that the ‘bouncy castle’ provider (instead of JDK) has been used in similar situations. Our working hypothesis was that WS2016 is just overzealous in negotiation when the newer ciphers are enabled or suggested first.

Our testing showed that switching the order so that the cipher still in draft status is not first was enough to allow the JDK based client to negotiate, which seems to support that hypothesis.

We rolled an order switch out, and plan to keep that in place for 6 months when the dependent application will be retired.

Some related links:

Leave a Reply

Your email address will not be published. Required fields are marked *

Required
Required