DirectAccess IP-HTTPS Null Encryption and SSTP VPN

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.

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.

50 Comments

Robert

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

Robertr

Hi 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

Mark Ringo

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

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

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?

ryan phillips

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

Anwar Mahmood

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.

Phil

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.

That 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

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

Thanks 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! 🙂

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?

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

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

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

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

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

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

Ryan Arnold

Andy

Yes, 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

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

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

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

I 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

Hi 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’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

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

Simply 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

Hi 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!

The 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

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

I’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. 🙂