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.

Leave a comment

6 Comments

  1. SC

     /  October 23, 2014

    Awesome, always an excellent resource, thank you for your research!

    Reply
  2. Greg Knowles

     /  June 8, 2015

    Based on my testing, disabling SSL 3.0 breaks Windows 7 DirectAccess Client functionality (at least when using IPHTTPS)

    Reply
    • Interesting observation. I’ve tested this thoroughly and implemented it for numerous Fortune 500 customers without issue. I suspect there’s something unique to your configuration that is preventing this from working correctly.

      Reply
      • Darren

         /  June 23, 2015

        I agree with Greg, we are using RRAS SSTP on 2012R2 combined with client certificate authentication and it messes up the certificate revocation check on the client. If you disable certificate revocation (not recommended or best practice in a production environment) on the client then it will connect. Reversing the SSL3 registry change resolves the issue.

      • Hi Darren. Greg’s issue was specifically with DirectAccess, which I’ve confirmed works without issue. I suspect there’s something unique in his environment that is preventing it from working. However. in your case with RRAS I can’t really comment on that. I’ve not performed any extensive testing for client-based VPN. SSL 3.0 is a legacy protocol though, and I find it difficult to believe that it shouldn’t work with SSL 3.0 disabled (assuming you aren’t running Windows XP of course!). I’ll conduct some testing when time permits and see if I can replicate. I’ll get back to you if I find anything interesting. 🙂

  3. Bruun

     /  January 14, 2016

    Also using DirectAccess and (SSTP) VPN on a single server, i’ve disabled SSL and everything is still working fine, no issues reported. As Richard mentioned it’s unlikely that it will “break” the config. XP doesn’t support SSTP VPN anyway 🙂

    VPN: SSTP PEAP-EAP-MSChapV2

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: