DirectAccess and the TLS Logjam Attack

Another critical flaw affecting Transport Layer Security (TLS) was discovered recently that could put some organizations at risk. The “Logjam” attack exploits a weakness in how the Diffie-Hellman key exchange is used. An attacker, acting as a man-in-the-middle, can potentially force a downgrade of the TLS connection, resulting in the use of weak cryptography. The Qualys SSL Labs SSL Server Test has been updated to identify this vulnerability. When testing a DirectAccess server you will receive the following warning message.

“This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.”

DirectAccess and the Logjam Attack

DirectAccess leverages SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, which is used to tunnel IPv6 packets over the IPv4 Internet. These IPv6 packets are encrypted using IPsec. If an attacker were to break the SSL/TLS connection they would gain nothing. Because of this, a dedicated DirectAccess server is unaffected by the Logjam attack. Mitigating it would provide no additional protection, so you can safely ignore the warning about weak DH key exchange parameters being supported.

However, if DirectAccess has been configured to use one-time password (OTP) authentication, the client-based VPN role has been enabled and configured, or the Web Application Proxy (WAP) role has been installed on the DirectAccess server, then the Logjam attack represents a serious risk and should be mitigated. Also, in some cases it may be desirable to make this change on a dedicated DirectAccess server just to prevent an audit finding and avoid having to explain why the DirectAccess workload would be unaffected by this attack.

To mitigate this vulnerability it will be necessary to remove support for cipher suites that use the Diffie-Hellman key exchange protocol on the DirectAccess server. This is accomplished by opening the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and expanding Computer Configuration, Administrative Templates, and Network. Select SSL Configuration Settings and then double-click SSL Cipher Suite Order. Select Enabled and then replace the default list of cipher suites with the following list.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA

DirectAccess and the Logjam Attack

Once complete, restart the DirectAccess server. The Qualys SSL Labs server test should no longer give a warning about the use of weak Diffie-Hellman keys. In addition, this reordering and optimization of cipher suites will also improve the protocol support and key exchange scores, as shown here.

DirectAccess and the Logjam Attack

As a reminder, and overall rating of “F” is expected when testing a dedicated DirectAccess server. By design, DirectAccess provides support for null cipher suites to improve scalability and performance for Windows 8.x and later DirectAccess clients. More details here.

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.