Microsoft first introduced support for null cipher suites for the IP-HTTPS IPv6 transition technology in Windows Server 2012, and it is supported for DirectAccess in Windows 8.x and Windows 10 clients. Using null cipher suites for IP-HTTPS eliminates the needless double encryption that occurs when using encrypted cipher suites. DirectAccess is a unique workload where SSL/TLS encryption isn’t really required because the payload being transported in HTTPS is already encrypted.
No Encryption by Design
When supporting Windows 8.x and Windows 10 clients, ensuring null cipher suites (TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256) are enabled and operational is crucial to providing the highest levels of performance and scalability for the remote access solution. When following implementation best practices, this isn’t really an issue. However, in some cases null cipher suites may be disabled. This will result in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients.
Validating SSL/TLS Configuration
The easiest way to verify that null cipher suites are being offered by the DirectAccess server is to use the Qualys SSL Labs server test site. Ideally you should see a result similar to this.
Figure 1. Qualys SSL Labs server test site results for properly configured DirectAccess server.
Don’t be alarmed by the overall rating “F”. That happens because the Qualys test site is designed to test web servers where using null cipher suites would be a serious security issue. As I stated previously, the DirectAccess workload is unique in that its HTTPS payload is already encrypted, so using null cipher suites is acceptable in this scenario.
Figure 2. Qualys SSL Labs server test site results for properly configured DirectAccess server showing support for null SSL/TLS cipher suites.
Null Cipher Suites Missing
When performing the Qualys SSL labs server test on a DirectAccess server, an overall rating of “A” is not desirable and indicates the DirectAccess server is misconfigured. This is caused by the lack of support for null cipher suites.
Figure 3. Qualys SSL Labs server test site results for misconfigured DirectAccess server.
Common Causes
Null cipher suites for SSL and TLS can be disabled for a variety of reasons. Below are some of the most common causes for the lack of support for null cipher suites for DirectAccess.
Self-Signed Certificates – Using the Getting Started Wizard (simplified deployment) will configure DirectAccess using a self-signed certificate for IP-HTTPS. Using a self-signed certificate is discouraged for numerous reasons, most importantly because it disables support for null cipher suites.
Security Hardening – Security administrators may proactively disable support for null cipher suites in a misguided effort to “improve security” for DirectAccess. While this is acceptable and recommended on a web server, it is not advisable to disable null cipher suites on a DirectAccess server.
SSL Certificate Signing Algorithm – Using an SSL certificate signed with an Elliptical Curve (EC) key as opposed to an RSA key will result in the loss of support for null cipher suites for IP-HTTPS. High security/assurance certificates signed with EC keys are not recommended for use on DirectAccess servers and should be avoided if possible.
DirectAccess Configuration Options – Enabling One-Time Password (OTP) authentication on the DirectAccess server will also result in a loss of support for null cipher suites. Also, adding additional roles to the DirectAccess server such as client-based VPN or the Web Application Proxy (WAP) can also result in null cipher suites being disabled.
Summary
Null cipher suites are implemented by design on DirectAccess servers to enhance performance for Windows 8.x and Windows 10 clients and improve overall scalability for the implementation. They eliminate the pointless double encryption of DirectAccess communication, which itself is already encrypted. For optimal performance and scalability, be sure to follow implementation best practices and use a PKI-managed (public or private) SSL certificate signed with an RSA key (SHA-256 recommended). Resist the urge to “harden” the DirectAccess server by disabling support for null cipher suites, and avoid the use of SSL certificates signed with EC keys. In addition, carefully consider DirectAccess deployment options such as OTP authentication and consider deploying roles such as VPN and WAP on a separate server.
Additional Information
DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites
DirectAccess IP-HTTPS Null Encryption and SSTP VPN
DirectAccess and FIPS Compliant Algorithms for Encryption
SSL Certificate Considerations for DirectAccess IP-HTTPS
Darren kemble
/ January 11, 2018Hi Richard,
I have carried out the changes I believed would enable Null Ciphers on my 2 DA servers, I had done the SSL test and was getting an A score back indicating Null ciphers were disabled, so I used IIScrypto on the 2 servers with the best practices option and made sure Null was ticked and also it was ticked in the ciphers suite tab. However when I do the SSL check after the changes the rating is still A and detecting strong ciphers etc. Is there anything else I can check, I was wondering whether my cert had the EC you reffered to but not sure how to tell.
Valid from Wed, 11 May 2016 11:03:38 UTC
Valid until Sat, 19 Jan 2019 12:06:38 UTC (expires in 1 year)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer Go Daddy Secure Certificate Authority – G2
AIA: http://certificates.godaddy.com/repository/gdig2.crt
Signature algorithm SHA256withRSA
Thanks for any help
Richard M. Hicks
/ January 11, 2018There are a number of other factors that can affect the use of null ciphers too. For example, if you are using an SSL certificate signed with an ECDSA key or if you have enabled OTP authentication then null ciphers will be disabled. There are a few other scenarios that will do the same too. If you’ll reach out to me directly I’ll have you send me some additional details about your environment and perhaps I an identify why null ciphers aren’t working for you.