This blog post is intended to help lay the groundwork to eventually setup and configure Mutual Authentication (Two Way TLS/Client Cert). For now, I will demonstrate how to just setup and configure basic SSL in IIS Express. For this exercise, I will be using a self-signed certificate that Visual Studio automatically generates and installs for us.
In the next blog, I will then show how to setup and configure a Client Cert for Mutual Authentication for your Web API. Finally, I will demonstrate how to deploy this to an Azure App Service and test using Chrome and Postman.
Prerequisites: Visual Studio 2017 Community Edition on Windows 10 Home Edition or similar development environment.
Assumption: You know C#, WebApi and do not need every exact step for creating a Web API project.
First, let’s start by creating an Empty WebApi project.
After clicking the “Ok” button, then check MVC and WebApi.
Then click “Ok” again. Now we are ready to add a new API endpoint. Right click on the Controllers folder and add a new Controller. Since this is a WebApi, make sure your controller inherits from ApiController.
Next, let’s add a test endpoint that returns various useful information:
public IHttpActionResult Get()
{
var testResult = new
{
ApiName = "SSLSample",
ServerInstance = Environment.MachineName,
Version = "1.0",
UsingSSL = (this.ActionContext.Request.RequestUri.Scheme == Uri.UriSchemeHttps),
HealthMeter = 100
};
return Ok(testResult); // Returns an OkNegotiatedContentResult
}
Next run and test the endpoint to verify that our endpoint works and returns the expected result using your favorite browser with the appropriate URL.
Note: Your URL may be different. Check the properties of your project for the URL your project is configured for. It will usually very by port number.
Now we know we have a working API. Let’s configure SSL.
Configuring SSL
This is really, really difficult so make sure your read carefully (note the sarcasm). Microsoft has really overly simplified this process compared to 10 years ago. First, right click on the project and click “Properties”.
In the “Properties” section, enable SSL.
Now, run the WebApi. The first time when your run the WebApi project, you will need to trust the IIS Express SSL Certificate.
Then another dialog will pop-up asking you to install the certificate.
Once this is up and running, let’s test the endpoint using HTTPS. Obviously, make sure your are using the appropriate URL when testing HTTPS.
Notice that both HTTP and HTTPS URLs will work. It is up to you to decide if you need to block access to your endpoints for HTTP. There are several ways to do that.
Conclusion
This blog has demonstrated how simple it is now to develop and run Web API in IIS Express using SSL. Ten years ago doing this was very convoluted and error prone. Now it is overly simplified so any developer can easily setup their dev environment to run SSL. Next, I will dive into Mutual Authentication for IIS Express.
What really? My security assessment failed because of my cookies. But I only use a couple of cookies to store certain user preferences. Those cookies are there only for user convince. Guess what? That third-party that ran the security assessment doesn’t care. All they care about is that you have cookies and that you are not securing your cookies properly.
You can easily pass your security assessment by opening Web.Config and setting the http Only setting to true and also turning on SSL for your cookies (assuming you only have SSL);
But you do need to understand the ramifications of these settings.
If your JavaScript is accessing your cookies then setting httpOnlyCookies to true will break your code. HttpOnly cookies help mitigate XSS and prevents cookies from being accessed vias client-side scripting. Therefore, depending on how your code is implemented may mean you have some refactoring to do.
Finally, my sites normally run using SSL only. Therefore, I set requireSSL to true. This only allows the cookie to be sent back over a connection using SSL/TLS. This is especially important with the Session Id cookie. You certainly do not want that to be passed over HTTP since that could be stolen and used to hack your site.
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.
Due diligence/Disclaimer
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:
Failed SSL
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”.
Failed 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:
Failed Ciphers
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.
Failed Handshake
Next, is to review the Protocol Details. This provides great information including links to read and review.
Failed Protocol Details
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.
IE Internet Options Advanced
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.
Run IISCrypto.exe
Click the configure Best Practices button. Turn off SSL 3.0.
Click Apply.
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:
Passed SSL
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.
Passed Protocols
Next, check the Cipher Suites:
Passed 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:
Passed 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.
Passed Protocol Details
Conclusion
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.
Doylestown Coder 