It is currently Mon Mar 18, 2024 11:15 pm

All times are UTC - 7 hours [ DST ]

Recent News:



Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Tue Jan 08, 2019 2:05 pm 
Offline
1TB storage
1TB storage

Joined: Sun Feb 18, 2018 12:39 pm
Posts: 49
Thanks: 0
Thanked: 3 times in 3 posts
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-


Last edited by Jachin99 on Fri Jan 25, 2019 10:46 am, edited 2 times in total.

Top
 Profile  
Thanks  
The following user would like to thank Jachin99 for this post
lioninstreet

Attention Guest: Remove this ad by Registering with the MediaSmartServer.net Forums. It's Free!
PostPosted: Tue Jan 08, 2019 8:40 pm 
Offline
1TB storage
1TB storage

Joined: Sun Feb 18, 2018 12:39 pm
Posts: 49
Thanks: 0
Thanked: 3 times in 3 posts
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:

Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
</configuration>


Top
 Profile  
Thanks  
PostPosted: Mon Nov 25, 2019 3:18 pm 
Offline
2.5TB storage
2.5TB storage

Joined: Sun May 19, 2013 9:40 pm
Posts: 399
Thanks: 46
Thanked: 50 times in 37 posts
Jachin99

Thanks for the detail on this. I'm curious if you would you expect a similar process if the client was w10?

_________________
Hi All, Thanks to everyone for your continued effort to keep the MSS & WHS alive. Haven't registered yet? Please do so the moderators know your here!

ex49x/v1 (toyin w/Vail)
VGA
Q8200s w/two 30mm cooling fans
4gb Ram
Rear Casecover Cooling Mod


Top
 Profile  
Thanks  
PostPosted: Thu Dec 05, 2019 9:05 pm 
Offline
1TB storage
1TB storage

Joined: Sun Feb 18, 2018 12:39 pm
Posts: 49
Thanks: 0
Thanked: 3 times in 3 posts
I haven't tried setting the ciphers for the connector application but that should work on win 7 or later as long as the version of Windows your using supports the cipher you specify if that's what your asking. I always enabled weaker ciphers for the connector setup and then disabled them again with iis crypto.

Honestly it's a cool experiment but I would weaken the ciphers for the connection process because the PC is on a LAN anyway.


Top
 Profile  
Thanks  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group