DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

Occasionally I will get a call from a customer that has deployed DirectAccess and is 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 2016 DirectAccess server indicate an overall rating of “F” and a score of “0” for the 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.

TLS_WITH_RSA_NULL_SHA256
TLS_WITH_RSA_NULL_SHA

DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Note: This doesn’t apply when the client-based VPN or Web Application Proxy (WAP) roles are also installed on the DirectAccess server, or if one-time password (OTP) authentication is enabled.  More details here.

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

Error 0x80040001 When Using OTP on Windows 7 SP1 DirectAccess Clients

Microsoft recently released a hotfix to resolve an issue where Windows 7 SP1 DirectAccess clients fail to connect to a DirectAccess server with the IP-HTTPS IPv6 transition protocol and using One-Time Password (OTP) authentication via the DirectAccess Connectivity Assistant (DCA) 2.0. In this scenario you may receive an HTTP 403 error from the DirectAccess server in response to the certificate signing requests and a 0x80040001 error after entering the OTP.

You can learn more about the hotfix for DCA 2.0 on Windows 7 SP1 and download the associated hotfix here.

Remote Assistance to Windows 7 SP1 DirectAccess Client Fails

Microsoft recently made available a hotfix to address an issue where Remote Assistance connections to remote DirectAccess clients fails. The issue occurs specifically when Windows 7 clients connect to a Windows Server 2012 DirectAccess server using the IP-HTTPS IPv6 transition protocol. In this scenario, DirectAccess clients are assigned a Unique Local IPv6 Address (ULA) using the prefix FD00::/8 for which Remote Assistance service would not listen on. If you are planning to support Windows 7 clients on your Windows Server 2012/R2 DirectAccess server and you need Remote Assistance functionality, you’ll definitely want to ensure that this hotfix is applied to all of your Windows 7 DirectAccess clients.

For more information and to download the hotfix, please refer to Microsoft Knowledge Base article KB2912883.