DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

Occasionally I will get a call from a customer who has deployed DirectAccess with Windows Server 2012/R2 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.”

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

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 2012/R2 DirectAccess server indicate a score of 50 for cipher strength.

DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

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


DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Note: This doesn’t apply when the client-based VPN role is collocated with DirectAccess. More details here.

Typically this could be remedied by disabling support for NULL cipher suites using the same SSL and TLS hardening techniques described here. 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.

Leave a comment


  1. Simon Day

     /  September 24, 2014

    Hi 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


  2. SC

     /  October 16, 2014

    how about the new SSL 3.0 problem (POODLE)? I assume turning off SSL 3.0 on the DA servers will be OK?

  3. Dor

     /  October 21, 2014

    Hi Richard,
    Will be happy to see your guidance about DA Servers and Poodle vulnerability.
    We are using WW DA solution.
    Thanks a lot

  4. SC

     /  March 30, 2015

    Soo 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..


    Do you think it would be safe to disable those on DA servers?

    • Hi 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.

    • 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.

  5. itismeap

     /  April 16, 2015

    Are there any directions on how to disable the RC4 suites in Windows 2012 R2?

    • In 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”)

  6. Kev Brown

     /  August 31, 2015

    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 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.

  7. Farmer

     /  May 12, 2016

    Hi 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:
    Is the Diffie-Hellman Key Exchange save to disable?

    • 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.

  8. RobC

     /  September 29, 2016

    I 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?

    • 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.

  9. If I disable TLS 1.0 then Direct Access fails for Windows 7 Clients. Do I need TLS 1.0 enabled?

  10. If I disable TLS 1.0 then Direct Access Fails. Should this be the case or should I be able to Disable it?

    • If 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.

  1. POODLE and DirectAccess | Richard Hicks' DirectAccess Blog
  2. DirectAccess and the TLS Logjam Attack | Richard Hicks' DirectAccess Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: