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.”
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.
Reviewing the details of the test results shows that the following two NULL cipher suites are indeed supported, highlighted below in red.
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.