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.
Simon Day
/ September 24, 2014Hi Emmanuel
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.
He’s also been helping with your Data Centre migration ☺
Best Wishes
Simon.
SC
/ October 16, 2014how about the new SSL 3.0 problem (POODLE)? I assume turning off SSL 3.0 on the DA servers will be OK?
Richard Hicks
/ October 20, 2014I’ll be publishing guidance on this tomorrow. Just wrapping up some final testing.
Richard Hicks
/ October 21, 2014Details about DirectAccess and POODLE here: http://directaccess.richardhicks.com/2014/10/21/poodle-and-directaccess/.
Dor
/ October 21, 2014Hi Richard,
Will be happy to see your guidance about DA Servers and Poodle vulnerability.
We are using WW DA solution.
Thanks a lot
D.L
Richard Hicks
/ October 21, 2014Just posted this morning. Let me know if you have any questions! http://directaccess.richardhicks.com/2014/10/21/poodle-and-directaccess/
SC
/ March 30, 2015Soo Richard, since RC4 weakness has come up again due to the “Bar Mitzvah” attack.. our DA servers and also yours in the screenshots above still show the RC4 related ciphers..
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Do you think it would be safe to disable those on DA servers?
Richard Hicks
/ March 30, 2015Hi Stephen,
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.
Richard Hicks
/ March 30, 2015One 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.
itismeap
/ April 16, 2015Are there any directions on how to disable the RC4 suites in Windows 2012 R2?
Richard Hicks
/ April 20, 2015In Windows Server 2012 R2 you can disable RC4 in the registry using the following PowerShell commands:
$writable = $true
$key = (get-item HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\).OpenSubKey(“Ciphers”, $writable).CreateSubKey(“RC4 128/128”)
$key.SetValue(“Enabled”, “0”, “DWORD”)
$key = (get-item HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\).OpenSubKey(“Ciphers”, $writable).CreateSubKey(“RC4 56/128”)
$key.SetValue(“Enabled”, “0”, “DWORD”)
$key = (get-item HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\).OpenSubKey(“Ciphers”, $writable).CreateSubKey(“RC4 40/128”)
$key.SetValue(“Enabled”, “0”, “DWORD”)
Kev Brown
/ August 31, 2015Hi,
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
Richard M. Hicks
/ September 1, 2015As 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
/ May 12, 2016Hi Richard,
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?
I also have the Diffie-Hellman Key Exchange enabled, but this will probably fix it:
https://www3.trustwave.com/support/kb/KnowledgebaseArticle14784.aspx
Is the Diffie-Hellman Key Exchange save to disable?
Thanks
Richard M. Hicks
/ May 13, 2016When 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.
RobC
/ September 29, 2016I have a new DA setup using 2012R2 with vpn setup using SSTP. Sellable reports that the server is offering those null encryption ciphers. Is this article still relevant?
Richard M. Hicks
/ October 19, 2016It 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.
Kev
/ October 5, 2016If I disable TLS 1.0 then Direct Access fails for Windows 7 Clients. Do I need TLS 1.0 enabled?
Richard M. Hicks
/ October 19, 2016If you plan to support Windows 7 clients then yes, you’ll need to re-enabled TLS 1.0 support on the server. 🙂
Kev Brown (@kkbroon)
/ October 6, 2016If I disable TLS 1.0 then Direct Access Fails. Should this be the case or should I be able to Disable it?
Richard M. Hicks
/ October 19, 2016If you are providing support for Windows 7 clients, then TLS 1.0 is reuqired. If you are supporting only Windows 8.x/10 clients, then you can safely disable TLS 1.0.
David Willetts-Smith
/ November 14, 2018I’ve disabled TLS 1.0 which you’ve said is fine for Windows 10 clients but they now fail to connect (DA Server is Win2k16) – Am I missing something?
Richard M. Hicks
/ November 17, 2018You 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.
ronanfahy
/ October 20, 2020Hi Richard
Old post i know, but you said “You can disable TLS 1.0 for DirectAccess in Windows Server 2016, but it isn’t recommended to do this because it breaks reporting” – can you elaborate on that?
thanks
ronan
Richard M. Hicks
/ October 24, 2020Disabling TLS 1.0 on Windows Server 2016 will prevent you from running historical reports using the Remote Access Management console. It doesn’t break any connectivity as clients can still connect and access resources, but administrators won’t be able to run reports. The recommendation is not to disable TLS 1.0 if at all possible, but if you have to, then know you won’t be able to run reports in the future.
IT Guy
/ September 25, 2018Hi 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.
Richard M. Hicks
/ September 27, 2018Yes, you most certainly can disable SSL/TLS ciphers that use 3DES. IISCrypto would definitely work. If you’re looking for a script, send me an email directly and I’ll provide you with one.
Willem Hamers
/ December 19, 2018Hey, 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
Richard M. Hicks
/ December 19, 2018If 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.