SBS 2011 Standard – Disable TLS 1.0
December 14, 2015 74 Comments
So you have completed a PCI Compliance scan, and you need to disable TLS 1.0?
You may have found the instructions here from TechNet which explain how to edit the registry to disable TLS 1.0, SSL 2.0 and SSL 3.0. What they don’t go onto explain is that this will break your RDP/RDP Gateway Connections.
Given that , as I understand it, the requirement to disable TLS 1.0 is being enforced from June 2016 I thought it was worth running through and sharing the process.
Before we start, I want to suggest you read through the whole process first. Also understand that I am documenting what happened in my lab system and by reading this aloud or in your head you waive any legal responsibility on my part in perpetuity throughout the universe.
Firstly, how are you accessing your server? We will be changing some settings that may cut you off without RDP access to get back. So, what is your backup plan? I am thinking iLO or DRAC.
We will change an RDP Encryption Level setting first. This should mitigate any potential risk to cutting you off.
Open up Remote Desktop Session Host Configuration, right click RDP-Tcp and then change the Security Layer to RDP Security Layer from Negotiate.
After you have applied this, confirm you can still RDP to your server.
Next open up Regedt32 and navigating to HKLM>System>CurrentControlSet>Control>SecurityProviders>SCHANNEL>Protocols
You will see that the SSL 2.0 protocol is defined, and by default the client component is disabled.
Before I make any changes, I am just confirming I can access my RWA page and an internal client, via RWA.
So armed with a confirmation we can go ahead and disable TLS 1.0.
Switching back to Regedt32 we can create a new Key for TLS 1.0, and then a new Key for Server, and finally a new DWORD to set ‘Enabled’ to 0.
You can do this manually if you like, or the PowerShell way.
New-Item "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS" –Name "TLS 1.0" New-Item "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS\TLS 1.0" –Name SERVER New-ItemProperty "HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\PROTOCOLS\TLS 1.0\SERVER" –Name Enabled –Value 0 –Type DWORD
The instructions on TechNet do not say if a reboot is required or not, a general rule of thumb I employ in this situation is to reboot, however before I did, I decided to try and verify if TLS 1.0 was off or not so I found an online SSL Report tool, in this case I am using the one at SSL Labs. https://www.ssllabs.com/ssltest/
Things did not look good.
The report confirmed TLS 1.0 was still active, so I rebooted the server and decided to try and lock down the other protocols.
Disabling SSL 2.0 seemed like a reasonable next step and is easy enough following the procedure above, after another reboot, I reran the scan expecting a result of at least C.
Well I was wrong.
Looking closer I found that whilst TLS 1.0 and SSL 2.0 were indeed, disabled, TLS 1.1 and TLS 1.2 were not and that TLS 3.0 was the only one available.
According to the documentation, to get TLS 1.2 enabled you need to create the ‘DisabledbyDefault’ DWORD and set it to 0.
I also enabled TLS 1.1 and disabled SSL 3.0.
That certainly improved the situation.
Looking at the results here, I decided to look at disabling RC4 as this was holding me back to a ‘B’.
Luckily, Microsoft released a patch for that. https://support.microsoft.com/en-us/kb/2868725
Unluckily, it seems, that patch did not apply to my SBS Server.
Characteristically I didn’t bother to actually read the KB, which indicates that after the patch is installed you need to edit the registry.
So, after editing the registry to disable the RC4 Ciphers, I rebooted and reran the scan.
At this point I enlisted the help of long time caller first time listener Tim Barrett, who was keeping me company on a Friday night when the cool kids are out on the town and I am home working on SSL PCI Compliance. Luckily for me Tim lives in the past so he was still at work.
He confirmed to me via several lab systems, that at this point, if you were accessing the RWA from a Windows 7 machine, you would not be able to access any Remote Desktops, but that Sharepoint and OWA were still working.
Internally we had a Windows 7, Windows 10 and of course the SBS 2011, we could not connect to any of these from an external Windows 7 client.
Whilst you could login to the RWA itself, any RDP connection attempted would result in this error.
He also confirmed via some his own lab servers and clients, that Windows 10 clients were still able to connect to internal RDP Connections just fine and I confirmed from my PC that Windows 8.1 was also still working.
This is what I was expecting and I directed Tim to install this patch on his Windows 7 system. https://support.microsoft.com/en-us/kb/3080079
However, after applying the patch we were still unable to RDP using the RDP Gateway, we did confirm that a direct RDP connection to the server or a workstation was successful, this, I was not expecting.
What followed was a weekend of trying various configurations and repeated SSL tests, I decided to call it a day on Monday evening when I realised I could not even get an SSTP VPN to connect.
This of course leaves us with a dilemma, we can be PCI Compliant and refuse RDP Gateway Connections from clients running Windows 7 or earlier, or we can retain those connections, leave TLS 1.0 enabled and not be PCI Compliant.
Not the great outcome I had hoped for when I started this post, but we can’t always get what we want!
After I had finished all of this I decided to lookup Forward Secrecy and stumbled upon this excellent piece of PowerShell. This script will take care of locking down much more than I have covered here and goes into a lot more depth with setting CIPHERING orders. The script will configure your server to support an ‘A’ rating on the SSL Test.
Note this script currently enables TLS 1.0 so please disable it after use.
Following the comment below from Bob, I decided I had not done as comprehensive a test as I thought I had. Indeed, whilst OWA and Sharepoint were confirmed to work, what about EAS what about TLS with SMTP?
Next I turned my attention to SMTP TLS. Using a reputable search engine, I found a website that would test a TLS connection for me. On a system where TLS 1.0 is enabled and functioning correctly, you will see that TLS 1.0 is negotiated.
Once you disable TLS 1.0, if you run the test you will see it fail.
Ater a reboot I reran the test and confirmed TLS 1.2 was now negotiated.
I am hoping Microsoft will release an additional patch to enable Windows 7 to work with an RDP Gateway Server using TLS 1.2, but we will have to wait and see!
I decided to try and run an actual PCI Compliance Scan against the server, which failed. However it did not fail on any TLS issues, it failed on some IIS vulnerabilities
I applied the two workarounds noted, which are to ensure a lockout policy is in place and that the administrator account was renamed, and that I believe was enough to change my status to Compliant.
(I did also tweak some IIS Settings to attempt to mitigate the HTTP Slow POST DDOS vuln, but not yet found the right combination of settings for that)
So as of the time of writing my SBS 2011 Standard is PCI Compliant. Whether or not this configuration will stay compliant after the 30th June, I cannot say.
I would expect Microsoft to release a patch to allow SQL 2008 R2 to function with TLS 1.0 disabled, prior to, or very soon after that June 30th deadline.
Thanks to commenter ‘Badadministrator’ I can tell you that Windows 7 can now operate using TLS 1.2 and RDP Gateway!
Following some comments below about SharePoint not working, i fired up my LAB machine to confirm what i had posted was correct.
Firstly i found my SharePoint was showing a 503 Service Unavailable Error. This was easily resolved using the method posted by Microsoft here.
Once this was done, i found i was presented with ‘An unexpected Error has Occurred” So i decided to walk back the changes i had made to the system in an attempt to get SharePoint at least functional before troubleshooting further.
The first thing i did was remove the FIPS GPO i mentioned above, i simply unlinked that particular GPO, i confirmed that the SQL Databases would not even start in this state. So next i re-enabled TLS 1.0. This of course required a reboot, but i confirmed after doing this SharePoint loaded as expected.
Next i did some research and found that as i half expected, Microsoft have indeed issued patches for TLS 1.2 for SQL and .Net. The first patch to apply is SQL Server 2008 R2 SP3. Reboot after applying this.
Next you will need to apply a second SQL 2008 R2 Update. KB3144114x64. Again reboot after applying this.
Thirdly a SQL Client Update is required.
New-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name DefaultSecureProtocols -Type DWORD -Value 1 New-ItemProperty "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name DefaultSecureProtocols -Type DWORD -Value 1 New-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name DefaultSecureProtocols -Type DWORD -Value 1 New-ItemProperty "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name DefaultSecureProtocols -Type DWORD -Value 1
Once you have done this you can Reboot and confirm SharePoint is still active, then you can Disable TLS 1.0 again.