POODLE and DirectAccess

Recently a new and very serious vulnerability in the SSL 3.0 protocol has been discovered that allows an attacker to recover sensitive information for an encrypted session. As DirectAccess uses SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, I’ve had many customers ask me about mitigating this vulnerability on a DirectAccess server.

POODLE and DirectAccess

Figure 1 – Qualys SSL Labs Server Test Score for DirectAccess IP-HTTPS

However, is mitigating the POODLE attack on a DirectAccess server really necessary? Recall that, as I’ve discussed previously, the IP-HTTPS IPv6 transition protocol is only used to tunnel IPv6 traffic from the DirectAccess client to the DirectAccess server over the public IPv4 Internet. This traffic is already encrypted with IPsec, so there’s really nothing an attacker would gain by leveraging the POODLE attack on a DirectAccess session.

The recommended mitigation for the POODLE attack is to disable the use of SSL 3.0 on servers and clients. If you have deployed DirectAccess by itself, there’s no need to implement this mitigation as there is no real risk associated with this attack in this specific scenario. However, there are no negative side effects for doing so, and if you wish to disable SSL 3.0 just to avoid future audit findings, I see no problem with that.

If your DirectAccess server is also configured to support client-based VPN and you’ve enabled the Secure Sockets Tunneling Protocol (SSTP) then mitigating the POODLE attack is an excellent idea. SSTP also uses SSL and TLS, so this session could be hijacked by an attacker and sensitive information might be disclosed.

To disable SSL 3.0 on the DirectAccess server, execute the following commands from an elevated PowerShell window.

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -PropertyType dword -Value 0 -Name Enabled

A restart of the server is required for the changes to take effect. To audit your DirectAccess server’s SSL and TLS configuration, visit the Qualys SSL Labs server test site. For more information about the POODLE SSL 3.0 vulnerability, click here.

DirectAccess and the Microsoft Surface Pro

With the recent release of the Microsoft Surface Pro, many people have been asking me about DirectAccess connectivity for these devices. One of the requirements for DirectAccess connectivity is that the device be joined to a domain, a capability that the Surface RT lacked. Although the Surface Pro runs the full version of Windows 8, it is Windows 8 Professional. Sadly, DirectAccess connectivity is only supported for Windows 8 Enterprise edition clients, along with Windows 7 Enterprise and Ultimate editions.

Windows Server 2012 DirectAccess Client Requirements

So, if you have just purchased a new Microsoft Surface Pro and are hoping to configure it as a DirectAccess client, I’m afraid you’re out of luck. In my opinion, the lack of DirectAccess support for Windows 8 and Windows 7 Professional is a serious flaw, especially when you consider all of the great use cases you can imagine when you have a full featured tablet with always-on, secure remote network connectivity. It’s a shame, really. Let’s hope this changes in the future!

Update: Read my post on how to install Windows 8 Enterprise and configure DirectAccess on the Microsoft Surface Pro here.

%d bloggers like this: