DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

Occasionally I will get a call from a customer that has deployed DirectAccess and is complaining about a security audit finding indicating that the DirectAccess server supports insecure SSL/TLS cipher suites. For example, when using the popular Tenable Nessus vulnerability scanner, a vulnerability report indicates a finding with a Medium severity level in the plug-in “SSL Null Cipher Suites Supported”. The description states that “The remote host supports the use of SSL ciphers that offer no encryption at all.”

You can confirm this finding by using the Qualys SSL Labs SSL Server Test site. You’ll notice that the test results for a Windows Server 2016 DirectAccess server indicate an overall rating of “F” and a score of “0” for the cipher strength.

Reviewing the details of the test results shows that the following two NULL cipher suites are indeed supported, highlighted below in red.

TLS_WITH_RSA_NULL_SHA256
TLS_WITH_RSA_NULL_SHA

Note: This doesn’t apply when the client-based VPN or Web Application Proxy (WAP) roles are also installed on the DirectAccess server, or if one-time password (OTP) authentication is enabled. More details here.

Typically this would be remedied by disabling support for NULL cipher suites using the common SSL and TLS hardening techniques. However, DirectAccess IP-HTTPS is unique in this scenario and the support for NULL cipher suites is by design, so employing traditional SSL and TLS security hardening techniques doesn’t apply here.

This is because DirectAccess IP-HTTPS is only used for IPv6 tunneling purposes, enabling the DirectAccess client that communicates exclusively using IPv6 to connect to the DirectAccess server over the public IPv4 Internet. IPv6 DirectAccess traffic from the client to the server is encrypted with IPsec, so the need for SSL/TLS encryption is not required, and in fact is not desirable for scalability and performance reasons. No unencrypted traffic (with the exception of ICMP) is sent over this SSL/TLS connection.

If a security audit flags support for insecure cipher suites on your Windows Server 2012/R2 DirectAccess server, you can safely ignore it.

32 Comments

Simon Day

I remembered when our DA health check report was reviewed some of your colleagues were concerned about changing the Cipher Suites settings.
Here is a blog post from Richard Hicks who is a prominent speaker about DirectAccess.

The point of the article was to demonstrate that SSL configuration on the DirectAccess server is irrelevant. SSL is used only for tunneling DirectAccess traffic, which itself is already encrypted. In fact, Windows 8.x and later clients use null encryption. If someone were to leverage an attack on the SSL channel they would gain nothing. However, in my experience it is often easier to mitigate these findings than have to explain to an auditor why the finding aren’t applicable. 🙂 With that, yes, you can safely disable support for RC4 cipher suites without affecting DirectAccess operation.

One more thought. If you are using the server exclusively for DirectAccess, everything I said earlier applies. However, if you have also enabled support for client-based VPN and you have users connecting with SSTP, then performing SSL hardening is vital. That includes disabling support for SSL3 and RC4 cipher suites.

Kev Brown

Hi,
I have somehow managed to disable Null encryption and I cannot re-enable it. I have searched the registry and it all looks the same as another direct access server I have but when I scan it on the website http://www.ssllabs.com it reports that Null Encryption is disabled. Can you please help as I have ran out of ideas. Thanks

As long as it is enabled in the registry at HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ (Key=NULL, Value=1) or not present in the registry at all then null ciphers should work. However, if you’ve configured VPN on the same server you’ll lose support for null ciphers even if they are enabled in the registry.

Farmer

About the Null cipher, we are now using MDA with exclusively Windows 8.1 clients. As you state, 8.1 clients use the Null cipher. But we are working to a situation where we enable the VPN with SSTP (PoC). So we need to disable the Null cipher (i presume, and of course also RC4 and SSL3).

When we do that the 8.1 clients will just use an other suite, but performance will be a bit lower? The Null Cipher is not required right?

When you enable VPN on the DirectAccess server, support for null encrypted cipher suites is dropped. You won’t have to proactively disable anything. There will be a performance hit for Windows 8/10 clients, yes. The server will also experience increased load too. If you’re using SSTP, I would definitely encourange you to perform SSL hardening. Disabling SSL 3 and optimizing cipher suites are important for VPN, but not for DirectAccess because the payload is already encrypted.

It is possible that something has changed since I posted this. I haven’t done any testing with this specific configuration in quite a while. In the past, when enabling VPN on the DirectAccess server, support for null cipher suites was disabled. However, if you’re not seeing that behavior then perhaps this no longer applies. I’ll do some testing again soon when time permits and update the post accordingly.

You can disable TLS 1.0 for DirectAccess in Windows Server 2016, but it isn’t recommended to do this because it breaks reporting. However, if you have a pressing need to do this (regulatory compliance, for example) then it should work. I’m not sure why it doesn’t work for you though. I’d have to look at your specific configuration to provide more information.

IT Guy

Hi Richard, Quick one (hopefully). I’ve been looking for confirmation that I can safely disable Triple DES 168 ciphers on our Direct Access server as a response to a Vulnerability audit. Would you be able to give any guidance around how best to do this? I am aware of the IISCrypto tool but I would feel happier doing this manually.

Willem Hamers

Hey, at this moment, what do you recommend as preferred cipher suite order for DA on win 2012 r2 with only DA. the screenshot form SSL labs is old I think? I have managed to enable NULL again, but what about the order? And yes I already had disabled some, because of our external vulnerability scan. Thanks for your reaction

If you are supporting only Windows 10 clients you don’t have to worry about the order. Just make sure NULL ciphers are enabled and you’re good to go. If you’re supporting Windows 7 it’s a different story though. Let me know if that’s the case and I’ll provide more detail.