An important scalability improvement introduced in Windows Server 2012 DirectAccess is the support for null encryption for Windows 8.x DirectAccess clients using the IP-HTTPS IPv6 transition protocol. Using null encryption eliminates the overhead imposed by the needless encryption of DirectAccess IPsec communication, which itself is already encrypted. This double encryption significantly increases resource consumption on both the client and server, and can have a negative impact on scalability and performance. When a Windows 8.x client establishes an IP-HTTPS connection to a Windows Server 2012 or 2012 R2 DirectAccess server, it will negotiate only cipher suites that use null encryption. Windows 7 clients cannot take advantage of null encryption and continue to use encrypted cipher suites.
Note: It is possible to replicate some of the benefits of null encryption for Windows 7 clients using an Application Delivery Controller (ADC) such as the F5 Networks Local Traffic manager (LTM) to perform SSL offloading. See SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP for more information.
For both performance and scalability, the best deployment results are achieved when using a Windows Server 2012 or 2012 R2 DirectAccess server and Windows 8.x clients. However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess. As you can see below, when DirectAccess is deployed by itself, the server offers null encryption cipher suites which Windows 8.x clients can take advantage of.
Figure 1 – Cipher Suites for DirectAccess Only
However, when the client-based remote access VPN role is enabled on the same DirectAccess server, null encryption cipher suites are no longer available for use by DirectAccess clients.
Figure 2- Cipher Suites for DirectAccess and VPN
This occurs because the Secure Sockets Tunneling Protocol (SSTP) client-based remote access VPN protocol requires SSL/TLS encryption to provide confidentiality for tunneled network communication. Unfortunately, disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely. Of course none of this is readily apparent to the administrator, who may be completely unaware that they’ve sacrificed the efficiency of IP-HTTPS null encryption for Windows 8.x clients in order to support SSTP for client-based remote access VPN clients.
Note: There are additional scenarios in which null encryption for Windows 8.x DirectAccess clients is not supported. For example, if you enable the Web Application Proxy (WAP) role on the DirectAccess server, or if you configure DirectAccess to use one-time password (OTP) authentication, null encryption support is lost for Windows 8.x clients.
If you plan to support Windows 8.x clients using IP-HTTPS and want to take full advantage of the scalability and performance benefits associated with IP-HTTPS null encryption in Windows Server 2012/R2 DirectAccess, it is recommend that you deploy client-based remote access on a separate system.
Robert
/ July 11, 2014Hi! You write
“disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely”
but how do I remove the VPN role? I cant see the NULL ciphers when checking DA address at http://www.ssllabs.com even though I clicked “Disable VPN” in the Remote Access Management Console (which says that the VPN will be removed).
/Robert
Richard Hicks
/ July 20, 2014Hi Robert. Sorry for the late reply. During my initial testing removing VPN support returned the NULL cipher suites in my test lab. I’ll test again just to confirm though.
Robertr
/ July 20, 2014Hi Richard! I noticed that it took a couple of days Before the cache att ssllabs was completely flushed, when I ran the test a couiple of days later the NULL cipher suite was there, as expected. Thanks for the reply!
/Robert
Richard Hicks
/ July 21, 2014Good to hear. Thanks for following up.:)
Mark Ringo
/ July 24, 2014Interesting article. I’m trying to optimize my performance for DirectAccess clients and was happy to see this article since my DirectAccess servers run both Client VPN and DA. When I execute the test on ssllabs.com against my servers it shows exactly Figure 1 (with Null Encryption in red). I was not expecting this result since the servers run both types of VPN. My pair of NLB DA servers are well-provisioned Hyper-V VMs and my service is 45 MBit synchronous. The very best that I can get is 12 MBit on the interface and only for a moment (the average is about 5). How would you go about resolving this performance problem? Thanks for any help.
Richard Hicks
/ July 25, 2014That’s unusual. I wouldn’t expect to see NULL encryption cipher suites offered if client-based VPN is also configured on the same server. Perhaps there is a scenario in which this is allowed that I haven’t tested yet? I’ll definitely look in to it. Regarding performance, it’s difficult to state why performance is less than expected. However, IPsec network processing is likely the culprit, especially in a virtual environment. The hypervisor in this scenario imposes a pretty steep performance penalty. You would probably see much better performance using a dedicated server.
ryan phillips
/ August 6, 2014I have setup DA 2012 R2 and not configured the vpn role. When I do the SSL test I am receiving the following back.
Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites always at the end)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 128, Ys: 128) FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 128, Ys: 128) FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
nothing about Null and a lot less entries then either of your images show. I’m noticing extremely slow speeds to a windows 8.1 ENT machine when both are connected to 1gb connections (I see 1mb/s) Any ideas on how to enable Null ciphers or any idea on how to speed things up?
Richard Hicks
/ August 7, 2014It appears that your DA server is configured to use suite-B algorithms only. You can enable/disable additional algorithms by following the guidance given here:
http://support.microsoft.com/kb/245030
ryan phillips
/ August 7, 2014Thanks for the reply, I looked through that and used a program called iis crypto that lets you enable and disable different ciphers etc. It doesnt seem to be working though. Can you give me an example of what I need to change in the registry?
Richard Hicks
/ August 12, 2014Have a look at this article:
http://www.isaserver.org/articles-tutorials/configuration-security/improving-ssl-security-forefront-threat-management-gateway-tmg-2010-published-web-sites.html
I wrote it for Windows Server 2008 R2 and TMG, but it should work for Windows Server 2012 R2 as well.
Anwar Mahmood
/ November 27, 2014This is a reply to Ryan Phillips message, but all help is welcome!
I have similar symptoms to you, but I am not even getting a connection.
I have described my situation at
https://social.technet.microsoft.com/Forums/en-US/b704b525-f324-4393-a61f-9d7d6732c7c4/directaccess-windows-server-2012-r2-windows-81-enterprise-tls-12-cipher-suite
Did it turn out to be the absence of NULL encryption? How did you fix it?
Anwar Mahmood
/ November 27, 2014For info, setting
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
“Enabled”=dword:ffffffff
to enable null encryption did not work.
Richard Hicks
/ December 3, 2014See my previous comment. Even though you’ve enabled the cipher suites, DirectAccess may not use them for Windows 8 clients because client-based VPN is enabled.
Richard Hicks
/ December 3, 2014Hi Anwar,
Is client-based VPN also configured on your DirectAccess server? If so, see the information here:
http://directaccess.richardhicks.com/2014/06/24/directaccess-ip-https-null-encryption-and-sstp-vpn/
Anwar Mahmood
/ December 3, 2014Hi Richard,
Thanks for your reply.
The Remote Access role was installed with just the DirectAccess role; no other role services were installed.
It turned out that the “outer” IP-HTTPS connection between client and server was established successfully, but the “inner” IPsec connection wasn’t. Configuring the firewall resolved this.
I still didn’t get to the bottom of NULL encryption. In my case, the wizard was not configured to use certificates. I did wonder if the “outer” IP-HTTPS connection is encrypted, but the inner “IPsec” connection isn’t using encryption.
Kind regards,
Anwar
Dev Ramdin
/ December 30, 2014Hi Richard,
I’ve discovered than when OTP is enabled the NULL cipher suites are also no longer available. Do you know if that is by design?
Thanks
Richard Hicks
/ January 14, 2015Absolutely. We don’t want credentials passed in the clear, which is why NULL cipher suites aren’t supported when client-based VPN is enabled. 🙂
Phil
/ January 15, 2015Hi Richard
We have exactly the same scenario as Ryan Phillips. We are using Windows Server 2012 R2 using a generic out of the box installation of Direct Access (without VPN), which created and used its own self signed certificate.
We have tried the suggested articles (SCHANNEL Registry etc) but the SSL Labs report only ever displays the same 6 cipher suites that Ryan reported.
Do you have and other ideas what could be causing this issue? Clients can connect and use DA successfully, but the performance is disappointing.
Thanks
Richard Hicks
/ January 16, 2015That certainly is unusual, and I’ve not encountered that in my testing. I have to assume that something is unique with your configuration that I’m overlooking. Also, keep in mind that when you repeat the SSL Labs test, be sure to click “clear cache” to complete run another test, otherwise it will report the results from your last test and now show any changes that you might have made. I’ve been bitten by that in the past. 🙂
Phil
/ January 20, 2015Thanks for taking the time to reply Richard, your clear cache advice is certainly a good one to remember but in our case we had already found that option.
Following your post I decided to go back to basics, I created a new test Windows 2012 R2 server in our test lab, applied no updates and just performed a Direct Access simple installation using the getting started Wizard. I then assigned the server a public IP address stuck it on the internet and tested on SSL labs, again we only had the 6 ciphers available that Ryan originally posted. To eliminate that the problem could be caused by Windows Server 2012 R2 I performed the same test but this time on Windows Server 2012, in this instance you only get 3 ciphers available.
My next thought was perhaps the issue was caused by the self signed certificate which is automatically created as part of the install. So I went back to my test 2012 R2 box and applied our godaddy wildcard SSL certificate to the server, assigned it to DirectAccess and performed the test again (this was without “tweaking” any of the SCHANNEL registry keys – just left default) and this appears to have solved our problem. The NULL ciphers now appear.
Richard Hicks
/ January 20, 2015Thanks for following up! I don’t ever use the “simple” DirectAccess deployment with self-signed certificates, so I’ve never encountered that issue. It’s definitely good information to know, so thanks for sharing. Yet another reason not to use self-signed certificates! 🙂
Gary
/ April 2, 2015Hi Richard,
Can you clarify, on the Qualys SSL test, our DA server does indeed show the 2 NULL encryption suites
TLS_RSA_WITH_NULL_SHA256 (0x3b) INSECURE 0
TLS_RSA_WITH_NULL_SHA (0x2) INSECURE 0
now, as I understand it, this is actually desirable for a direct access URL as in windows 8.1 as it is utilised to avoid double encryption. However, testing your direct access will always net an F rating on this site due to these 2 cipher suites. Provided the rest of our results are up to snuff, we can safely ignore this warning right?
Richard Hicks
/ April 2, 2015That’s correct. A dedicated DirectAccess server (without VPN installed) that doesn’t have OTP authentication configured will always receive an “F” rating from the Qualys SSL Labs test site. This happens, as you noticed, because in this configuration DirectAccess makes use of cipher suites that use null encryption. This is done to eliminate the protocol overhead of double encryption for Windows 8.x and later DirectAccess clients using the IP-HTTPS IPv6 transition protocol. It’s important to remember that the SSL Labs server test is designed expressly for web servers. DirectAccess is a unique workload that uses HTTPS purely as a tunneling mechanism for IPv6 traffic, which of course the SSL Labs test isn’t aware of. Obviously not using encryption on a web server is probably a bad thing, but for DirectAccess it’s ok because the payload is already encrypted.
Marcus
/ April 23, 2015Hello there, we have the same problems here, crazy thing is, that one of our 2 Windows 8.1 machines can connect without any problem, no error messages in server eventlog. The new client cannot connect, causing the 36888 and 36874 ids in the system log of the server.
This is the result of the SSL Test, no NULL cipher visible.
The question is, why can 1 client connect and the other not? The working client has an older client certificate, may that be the reason?
THanks in advance, Marcus
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 128, Ys: 128) FS WEAK 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 128, Ys: 128) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
Richard Hicks
/ April 24, 2015If one client can successfully connect, you know that the server is configured correctly. I’d look closely at the configuration of the client. Correct SKU? Certificates in place? Were the DirectAccess GPO settings applied? I expect you’ll find something missing on the client side somewhere.
Marcus
/ April 24, 2015Hello Richard, Windows is 8.1 Enterprise, certificates in place. The Client connects for a couple of seconds but then disconnects again, leaving the error Messages in the System log and some 4653 Errors in the security log. Checked everything, even reinstalled the Client, also with Windows 10 Enterprise, still same error… freaking out.
Richard Hicks
/ April 27, 2015Puzzling, but I still suspect something on the client side, as you stated previously that you have some clients connecting successfully. You may need to gather additional information using detailed event logging to netsh tracing. It might be best to open a support case with Microsoft so they can assist in gathering this information and interpreting it for you.
Ryan Arnold
/ July 22, 2015Great post Richard. We currently have VPN and DA on the same server and have a multi-site configuration. I have a few questions:
1) How can I remove the VPN role, but keep DA intact?
2) Since we’re using a multi-site configuration, a subca or rootca cert is required. Our current cert is sha-1/rsa and works just fine. We’re in the process on migrating to a new PKI which is sha256/ecc. From the testing I’ve done, the IPSEC connection is failing with the new SubCA cert inplace. Do you know if ECC is supported for the SubCA/RootCA cert?
Richard Hicks
/ July 24, 2015You should be able to remove client-based VPN and leave DirectAccess intact by issuing the following PowerShell command – Uninstall-RemoteAccess -VpnType VPN.
Richard Hicks
/ July 24, 2015SHA265 work just fine, but ECC is not natively supported for DirectAccess unfortunately. :/
Ryan Arnold
/ November 15, 2016Over a year later, but just wanted to say thanks!
Andy
/ October 21, 2016Hi, is there a way to tell if a client is using null encryption?
Richard M. Hicks
/ October 24, 2016Yes, you can do this by installing a protocol analyzer such as Wireshark on your client and monitoring the IP-HTTPS connection. You can verify that the server supports null SSL/TLS cipher suites by using the Qualys SSL Labs server test site or by using Nmap and the SSL-enum-ciphers script.
Andy
/ November 1, 2016Thanks Richard. I seem to have the missing null ciphers along the lines of others on here. In my case 2012r2 no VPN installed no OTP installed. Using Global sign certs. Tried the registry change to enable null but still no go. Any other ideas?
Richard M. Hicks
/ November 2, 2016I’ve run in to this issue a few times. If enabling null cipher suites via the registry (using the registry editor, PowerShell, or IISCrypto) doesn’t work, I’ve usually ended up rebuilding the server. Next time it happens I might open a support case with Microsoft just to see if there’s another way to resolve that without having to wipe and reload. 🙂
Biagio
/ July 20, 2017Great article!
We’re facing the problem with the missing null cipher suites on our DA Server. The VPN Role has been deinstalled and the null cipher suite has been activated through the registry editor, but we still don’t see any null encryption suites on the server.
Is a fresh install still the only option to reenable the null encryption suites?
regards
Richard M. Hicks
/ July 20, 2017I can tell you from experience that it is sometimes impossible to get null cipher suites back after they’ve been disabled, even after re-enabling them on the server via the registry. I don’t have any idea why that happens, but it does. I’ve been forced to rebuild servers on more than one occasions when this scenario occurs. However, before you go that far, make sure your SSL certificate is using RSA and not ECDSA. Certificates signed with ECDSA won’t ever support null cipher suites. 🙂
liew
/ September 3, 2017Hi my SSL certificate for my DirectAccess server certificate is Suite B compliant using ECDSA. My client cannot connect to DirectAccess server using ip-https. My setup works if the certificate issued is from RSA. This symptom is similar as your last post. May I know if there is a Technet link that supports this?
I found an old link not contradicts.
https://technet.microsoft.com/en-us/library/ee382307%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 Under Section “Using Suite B certificates for DirectAccess”
Richard M. Hicks
/ September 5, 2017I’m not aware of a specific reference document on Microsoft TechNet, but I can tell you from experience that using an SSL certificate that uses ECDSA won’t work for DirectAccess. This is because Windows 8.x/10 clients use only null encrypted SSL/TLS cipher suites, which aren’t supported when using an ECDSA certificate. Your only solution will be to use an RSA certificate. To be honest, using an ECDSA certificate on the DirectAccess server isn’t critical anyway. After all, HTTPS is used only for tunneling, not security. Null cipher suites are used because the payload is already encrypted. 🙂
Nik
/ December 19, 2019I also faced the problem with Null Encryption on the 2012 and Win10 clients that worked well for years but suddenly stopped… perhaps because of some update. I did investigation and found that Client Hello offers three Null Cipher Suites for negotiation but server does not offer it, probably because as Richard explained it shares DA and SSTP on the same server, so I getting errors 36874/36888 as others. I can’t move or remove SSTP as I need it and basically I was okay with performance. The question is: if I can’t add Null suites to the server, how to prevent clients to use it??? And why did it worked well so many years?
Richard M. Hicks
/ December 19, 2019Simply adding the null ciphers back to the DirectAccess server won’t restore functionality. The only solution is to make sure the configuration options that remove it aren’t enabled, and that the SSTP workload is on another server. If you can’t do that, you’ll have to live with IP-HTTPS and encrypted ciphers unfortunately. :/
Nik
/ December 21, 2019Hi Richard, thanks for reply. I don’t mind not to have null ciphers on the server. The issue is how to switch clients to use non-null ciphers. According to Wireshark trace, clients only try to use three ciphers, all of them are null. As a result, I’m getting handshake error. Perhaps, it’s something new for Win10 1909 build. Again, that config has been working for years but suddenly stopped!
Richard M. Hicks
/ December 24, 2019The clients should not be using null ciphers if the server doesn’t support them. However, this can only work when a role on the server doesn’t support null ciphers. For example, if you enable OTP authentication for DirectAccess, or add the VPN or Web Application Proxy (WAP) role on the server, DirectAccess knows that null ciphers aren’t available and the DirectAccess client settings GPO is updated accordingly. However, if you simply disable null ciphers directly, DirectAccess won’t be aware of this and assume they are. That’s when the client breaks.
NIk
/ December 24, 2019Richard, thanks for feedback. The clients should not be using null ciphers if the server doesn’t support them but the problem they do. Could you please specify where clients GPO can be adjusted for ciphers to use? Actually, I do not aware about such. If you’re talking about “cipher order” then this setting is disabled by default and none of server settings change this GPO. Moreover, if I manually enable this setting and remove null ciphers from the client GPO, it actually removes them but does not bring non-null ciphers instead. If I remove all three null ciphers from the “cipher order” client GPO, then a client simply does not expose “Client Hello” at all, so a tunnel does not even try to establish.
So after solid 36 hours troubleshooting where I checked every single “DirectAccess” link in Google 🙂 I gave up and now am trying to switch to Always-On VPN.
Richard M. Hicks
/ December 29, 2019I’m not sure where specifically in the DirectAccess client settings GPO the option to use null ciphers is set. I know from experience that Windows 8.x and later DirectAccess clients will prefer (and use exclusively) null ciphers for IP-HTTPS, and automatically revert back to using encrypted ciphers when the server no longer supports it (for example when OTP authentication is used or when a role such as VPN or WAP is installed). Why that isn’t happening for you I have no idea, unfortunately. :/
Always On VPN has its own unique challenges, but it is much less complicated than DirectAccess and doesn’t require all of the IPv6 transition and translation technologies, which is helpful. 🙂