|Securing Remote Web Access in WHS 2011 Part 1 Secure Ciphers
|Page 1 of 1|
|Author:||Jachin99 [ Tue Jan 08, 2019 2:05 pm ]|
|Post subject:||Securing Remote Web Access in WHS 2011 Part 1 Secure Ciphers|
EDIT: After living with this configuration for some time I noticed the Client Computer Backup Service on the server would regularly fail. In order to remedy this issue I Enabled SSL v3 and TLS v1. After I create a few new backups for my PCs I'll try disabling SSL 3 and TLS 1 each one at a time and note any changes. I'll also investigate whether I can set my RWA security protocols separately from those protocols used on my LAN.
This post is meant to walk users through the process of securing the cipher suites used for remote web access in WIndows Home Server 2011. Common sense applies here so do a full backup and read the entire post before starting this. If you can only RDP into your server then you need a recovery plan if for some reason RDP breaks and you can't fix it. I have a mediasmart, and I performed this entire procedure via RDP with no problems. Most Importantly, UPGRADE RDP, THEN PERFORM STEP 4, THEN DISABLE CIPHERS. Doing this out of order may result in you having no way to rdp into your server. Reading through this post, you will be directed to upgrade RDP on WHS & Win 7, change RDP security on your server, then remove weak ciphers and protocols via IIS crypto. There are a few adverse effects after doing this but nothing that cant be overcome. These include being unable to log in via RDP with the Launchpad running (You can simply close the launchpad, and RDP into your server), and the client connector application being unable to connect until you re-enable some weaker protocols(You can enable these protocols, connect your new PC, then disable them again after you setup things up). I am currently using this configuration with a godaddy cert for RWA that I was able to import after much uncertainty and a little bit of heartache. In order to secure RWA & RDP you will need a few downloads provided in the link a the bottom of this post. These include nartec IIS Crypto, which allows you to easily update your cipher suites, and a few windows updates that allow RDP to connect via newer ciphers. This procedure gave me an A grade on the openssl labs scanner at https://www.ssllabs.com/ssltest/ .
Step 1: Download Windows update KB4074621 for Win 7 and Win Server 2008R2. You will need to update both, and you can read more about this, and download the updates from https://support.microsoft.com/en-us/hel ... r-2008-sp2
Step 2: RDP into your server if necessary, and install the Win Server update. The update won't break your current session but as soon as you close this out, you may not be able to log back in using the old cipher suites until you update your Win 7 box so stay logged in for the time being. Windows 10 doesn't need the update because newer ciphers are already supported, and if for some reason your unable to log in after the server update on win 7 try win 10 if available.
Step 3: Install the update on your WIn 7 box. From here on out you will not be able to RDP into your WHS2011 box with the lanchpad running on Win 7. So if you get errors, try closing the launchpad.
Step 4: I did this based on the recommendation from https://windowsserveressentials.com/201 ... e-tls-1-0/ but I'm not sure I needed to. Open the Remote Desktop Session Host Configuration then right click RDP-TCP and choose properties. Under General set the security level to negotiate. I haven't researched this too much but it sounds like negotiate will provide better compatibility, and RDP security layer will provide a more strict policy enforcement. In the next step we will be disabling Older TLS protocols, and SSL entirely anyway.
Step 5: Run IIS Crypto, and choose your policy. I have included the policy I use, which gives me an A grade on the SSL Labs test. You can choose any policy you like but at a minimum I suggest disabling SSL, and TLS v1 even if you have applied one of the build in policies, unless you know of some application or capability you need depends on these. From here, restart both the server, then the client, and test RDP, and run the openssl test to view your enabled encryption protocols and ciphers.
After doing all of this, I tested the dashboard, Remote Web access, and RDP and they all worked. Once again, there are a few caveats that go along with this procedure. Disabling either TLS V1, or SSL v3 breaks the connector application connection process. This means when you want to add a new PC to your server by downloading the connector from the server you will need to rerun IIS crypto and enable those protocols. After you have connected your new client, and everything is working you can disable those protocols once again. After doing all of this, I tested the dashboard, Remote Web access, and RDP. They all worked.
The windows updates, IIS Crypto, and a template for my IIS crypto configuration are all available here
https://drive.google.com/open?id=1S4XD0 ... Js0GjX6mk-
|Author:||Jachin99 [ Tue Jan 08, 2019 8:40 pm ]|
|Post subject:||Re: Securing Remote Web Access in WHS 2011 Part 1 Secure Cip|
I haven't verified this works but it looks like a possible workaround for enabling strong ciphers and retaining the ability to add new PCs via the downloaded connector.
Forcing an old .net application to support TLS 1.2 without recompiling from Kevin Chalet via: https://kevinchalet.com/
As most servers are moving toward TLS 1.3 and removing TLS 1.0/1.1 support, examples of legacy .NET applications – compiled with an old version of the .NET Framework, like 4.0 or 4.5 – experiencing connectivity issues with TLS 1.2 servers are becoming more and more common, specially since installing a more recent version of the .NET Framework is not sufficient: it's the version used for compiling your project that actually matters when it comes to selecting the supported TLS versions during the TLS handshake.
To make migration a bit less painful, Microsoft published a list of transport security best practices that list a few solutions that help avoid handshake errors related to the use of legacy TLS versions that are no longer considered safe.
One of the proposed solutions is to update your project to target .NET Framework 4.7: in this case, you'll have nothing else to do, as .NET 4.7 applications automatically default to whatever the operating system they run on offers and considers safe (which currently includes TLS 1.2 and will later include TLS 1.3).
Unfortunately, such an option requires re-compiling the application, which is not always feasible. Thankfully, you can also force an existing application to use the system default TLS versions without having to re-compile it (assuming it doesn't explicitly set the SSL/TLS versions it prefers via ServicePointManager).
The best practices paper lists a few options, but my favourite one is the one that consists in simply updating the configuration file associated with the application executable, as it's easy to do and doesn't impact anything else on the machine.
For that, locate the configuration file associated to the executable of the application you want to add TLS 1.2 support to: it's always named [name of the executable].exe.config. If there's no such file, create one. Once located or created, update its content to enable the compatibility switch required to support TLS 1.2:
<?xml version="1.0" encoding="utf-8"?>
|Page 1 of 1||All times are UTC - 7 hours [ DST ]|
|Powered by phpBB® Forum Software © phpBB Group