So you built this awesome business web app. You sold it to your customer and it’s now in production. You’re using SSL which is even configured for best practices. See my previous post on securing SSL. But what happens when a user goes to your web application. It probably redirects them to HTTPS so the user can login over SSL.
Why do that???
That is the question to ask yourself. Why redirect users from HTTP to HTTPS to login. Why not ALWAYS use SSL??? I really do not believe you need HTTP or Port 80 turned on at all for business web applications. Here are my assumptions with Business Web Application:
Most interactions with your site is behind the login page. By most, I really mean like 99%.
The data is sensitive, company proprietary, etc…
You have employee information, financial information, etc…
So in this scenario, there is no real reason to have HTTP bindings setup in IIS for your site. Turn port 80 off on the firewall and only allow Port 443. Don’t even give the hacker a chance to see the traffic over HTTP or an avenue to hack your server over port 80.
But what about the customer???
They won’t know to use HTTPS… For me this is pretty easy answer. When sending the welcome package to your customer, explain to them why you did this and tell them the URL is only accessible over HTTPS. I have been doing this for years and yes we have had a few calls to the help desk. But VERY, VERY few calls.
You delivered your awesome business application and it’s running in production. You are a developer and have some limited System Admin skills so obviously your company decided you were the perfect person to set up your production environments. The data is sensitive so obviously you have SSL turned on. Everyone involved is in ecstatic!!! Then out of the blue, your customer calls to schedule a security assessment. First thought might be “I have SSL so that should be fine, but I’m nervous about my login page, XSS, CSRF, SQL Injection, etc.” News flash: SSL has vulnerabilities!!! And it is very easy for third-parties to identify those issues with your site during a security assessment. But even better, it is VERY easy for you to determine that your site has vulnerabilities so take the time to test your site (even if you are not the system admin) and fix it before your site goes live.
This is to provide you guidance. You must do your own due diligence and validation by testing first in a non-production environment. Also, changing Cipher security in Windows Server may disable RDP so be very careful!!!
This article is written based on Windows Server 2008 R2. I have not tested with Windows Server 2012 but am fairly certain it should apply.
Which OS are you using in production? I highly recommend having at least Windows Server 2008 R2. If you only have Windows Server 2008 you will not be able to fix several items with your SSL. You will probably need to start a migration plan.
In addition, you need to understand the browsers you support. That is rather easy for my specific scenario. I only support IE. My biggest problem has been getting users off of older versions of IE. Here are a couple great links to read up on:
Well that is for you to decide based on your content and it’s sensitivity… I believe anything that requires an account (username and password), bank information, credit card information, personal information, … then you should be very concerned and take this seriously.
If you want to be scared to death about using free WiFi at your local coffee shop or at the airport, then check out Troy Hunt’s site and read his articles about the “Pineapple“. That concerns me the most due to some of the sensitive info my applications have.
Start by testing your site:
This is very easy to do. Navigate to the following url: https://www.ssllabs.com/. Then click “Test your server” which will take you to a page like this:
Obviously, you do now want to see this:
Once your review your grade, there are additional details to review. Normally, my certificate is not an issue. So let’s jump ahead to the next section that is rather important: “Protocols”.
Notice that TLS 1.2 and 1.1 are not turned on; however, modern browsers support them so it is important to have them turned on. SSL 2.0 is not secure and has not been so for years; therefore, this protocol needs to be turned off. In addition, I turn off SSL 3.0 too. The next section to reviews is the Cipher Suites:
This order is not good. It is the default out of the box for Windows Server 2008 R2. It is so easy to fix. More to come on that later. Next, you should review the “Handshake Simulation”. I only support IE so I only review those. You may support many browsers. You want the browser to support Forward Secrecy which is denoted with FS. You can see that none of the handshake simulation supports FS and some even support RC4 which is an issue too due to vulnerabilities discovered last year.
Next, is to review the Protocol Details. This provides great information including links to read and review.
Before Fixing your server
You must be very careful. If you turn off all of the RC4 protocols you may disable RDP. See the following article:
In addition, your users may have TLS turned off by default or due to company policy. They will need to turn it on in IE under the Advanced tab for Internet Options; otherwise they will not be able to connect to your site.
How to fix your SSL
Luckily, fixing your SSL issues is very easy for Window Server 2008 R2. First start by downloading IISCrypto.exe from Nartac.
After downloading, I ran my virus scanner against the file just to make sure there is nothing suspicious. You never know if that site was hacked. If you are wary about using this executable, you could write your own by following the Microsoft Support article.
The Nartac IISCrypto follows the recommendations by Microsoft at the following site:
Follow these instructions for configuring SSL on your Windows 2008 R2 Server:
Take any backup precautions as you see fit. You will be changing the registry.
Click the configure Best Practices button. Turn off SSL 3.0.
The tool marks some registry keys incorrectly according to the Microsoft Support article. It uses 0x99999999 which may be fine but I update them anyway to reflect the values in the support article.
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate the following registry key/folder: HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0
Ensure that the DisabledByDefault key shows 0x00000000 (0) under the Data column (it should by default). If it doesn’t, right-click and select Modify and enter 0 as the Value data.
Repeat step 8 for SSL 3.o. If you want SSL 3.0 turned off, then make sure the “Enabled” value is 0x00000000 (0); otherwise, it should be 1.
Then repeat for TLS 1.0, 1.1, and 1.2 making sure “Enabled” is set to 1.
Restart the computer.
Re-validate your SSL using SSLLabs.com, ServerSniff.net or the Public SSL Server Database
Results using SSL Labs
Now that the server has been properly configured, you should see these results:
Now you can see that my production site only support TLS 1.0, 1.1 and 1.2. I have turned off SSL 2.0 and SSL 3.0.
Next, check the Cipher Suites:
Notice the order that the Ciphers are in. Note: I keep the RC4 Cipher. From what I understand this is necessary for RDP. There may be a way to configure RDP to use a different Cipher but until I have time to figure that out, I am keeping this Cipher.
In addition, notice how the FS (Forward Secrecy) ciphers are at the top.
Next, check out the handshake:
Remember, I am only concerned about IE 7 and above. We will be dropping support for IE 7 soon and IE 8 on XP. The rest of the handshakes for IE are using FS which is great! You may need to support multiple browsers so you will need to test accordingly.
Finally, check out the Protocol Details.
I hope this article helps those of you with limited System Admin skills. It took me a while to figure all of this out since my main occupation is Software Architect/Sr Developer… I am definitely not a System Admin but as a developer I do understand the importance of secure coding as well as following best practices on my production environments.