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.
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.
SC
/ October 23, 2014Awesome, always an excellent resource, thank you for your research!
Greg Knowles
/ June 8, 2015Based on my testing, disabling SSL 3.0 breaks Windows 7 DirectAccess Client functionality (at least when using IPHTTPS)
Richard Hicks
/ June 10, 2015Interesting 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.
Darren
/ June 23, 2015I 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.
Richard Hicks
/ June 26, 2015Hi 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. 🙂
Bruun
/ January 14, 2016Also 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