Outbound SSL Inspection with TMG Firewalls (Part 1)
If you would like to read the next part of this article series please go to Outbound SSL Inspection with TMG Firewalls (Part 2).
One of the best features included in the new TMG firewall is the outbound SSL inspection. Previous versions of the firewall, starting with the ISA 2000 firewall, supported inbound SSL inspection, something that we got to know as “SSL bridging”. With SSL bridging, we could crack open the SSL session by terminating the SSL connection at the external interface of the firewall. Then, the ISA firewall performed application layer inspection on the content. When the inspection is passed, a new SSL session could be created with the published Web server. Essentially, the session is encrypted from end to end and is exposed to application layer inspection.
While SSL bridging went a long way at securing inbound connections through the ISA and TMG firewalls, it was helpless in outbound scenarios. Without outbound SSL bridging (which from this point on we will call outbound SSL inspection), the firewall is helpless to protect you against what is contained within the SSL session. In fact, the outbound SSL session is the same, from a security viewpoint, as an outbound VPN session – the firewall is blind and helpless against any attacks or malware contained within the VPN session.
There is a good reason why we do not allow outbound VPN session from secure networks. We have known for a long time now that VPN sessions are encrypted, and thus, are impervious to firewall control mechanisms. Since we knew that the firewall could not protect us, we did not allow outbound VPN connections from our secure networks. We just did not know the level of security applied to the destination network on the other side of the VPN, and we did not want to risk the exposure of our network to whatever might be contained on the unknown network that would be joined to ours over the VPN.
But SSL seemed to be different. We have all been taught that SSL is a “security” technology. Thus, if we use SSL, we should be “secure”. The problem is that SSL is a technology that is, like VPN, primarily about privacy. Privacy is certainly a component of security but is not the only one. The challenge network security guys have is that while privacy in general is a good thing, nothing is universally good, and that privacy also prevents our network security gateways from doing their jobs.
To understand the security risks in allowing outbound SSL connections, first think about how modern malware works. Typically, the user gets infected by clicking a link in an e-mail message and becomes compromised in a drive-by or perhaps from connecting compromised media to their computers. The malware does what it needs to do on the infected machine to begin the process. One of the things that modern malware often does is to connect to servers on the Internet to download more malware and information required to carry out more sophisticated attacks. In the past you did not have to worry too much about this, since your anti-malware gateways would block the malicious code.
However, today’s bad guys are in it for money, and are using new and better ways to get around your defenses. One such way is to get around your very expensive Web filtering and anti-malware products is to use SSL sessions on their servers. Since they know that your high-dollar defenses can not do outbound SSL inspection, the infected machines can easily circumvent your Web filtering investment, since they can not see the malware within the SSL tunnels. Now, the hackers have taken over your assets and all this because your current solutions are not able to inspect the contents of SSL sessions.
This is just one example of why outbound SSL inspection is so important. That is why I think outbound SSL inspection is one of the key features included in the TMG firewall. Outbound SSL inspection is not new, and there are several products on the market that can do it. However, they are generally very expensive, very difficult to install, difficult to configure and manage, and finally, are not part of your overall Microsoft management and monitoring infrastructure. In contrast, the TMG firewall integrates tightly with the rest of your infrastructure, and you are also able to leverage your existing Windows and ISA firewall skills.
At this point I need to mention that ISA firewalls do not support outbound SSL inspection out of the box. This has been a major security weakness in the ISA firewall. However, that security weakness is easily mitigated by using a product such as Collective Software’s ClearTunnel. ClearTunnel enables the ISA firewall to perform outbound SSL inspection and gives you the visibility into SSL encrypted sessions you need to prevent malware downloads.
So what does it take to get outbound SSL bridging to work? From a high level, you need to do the following:
- Install the TMG firewall
- Create the Web Access Policy
- Examine the Outbound SSL Inspection Configuration
- Install the Firewall Client on the Client Computer
- Access SSL Sites and Observe SSL Inspection and Detection
I am not going to show you how to install the TMG firewall in this example. I can tell you that installing the TMG firewall is very easy. In fact, it is even easier to install than the ISA firewall, and there are a number of improvements in the installation routine included with the TMG firewall that were not available in the ISA firewall which I am sure you are going to like. For this reason, I will leave the articles on installing the TMG firewall in a number of different scenarios for another time.
In the walkthrough we will do here, the TMG firewall is already installed as an edge firewall. The figure below shows the general configuration of the lab environment.
As you can see, there is a domain controller running Windows Server 2003 Enterprise edition, a client machine running Windows Vista SP1, and a TMG firewall running TMG Beta 3 on Windows Server 2008 Enterprise edition x64. These three machines are running in a virtual lab environment, using VMware Workstation 6.5.1 on a Core i7 920 quad-core machine with Intel VT and hyperthreading enabled, and the host machine contains 12 GB of triple channel DDR3 RAM. The internal interface of the TMG firewall, the DC and the client are configured on VMNet2, and the external interface is bridged to the live network.
I typically do not make it a point to call out the specs of my host machines, but since this is a new workstation, I wanted to tell you how amazing the performance is for this virtual environment. If you have not had a chance to test out any of the new Intel Nehalem based Core i7 processors, or the new Xeon 5500 series processors, with fast triple channel DDR3 RAM, you should make it a point to do so. People have been telling me that these new processors and RAM are “so fast that it’s silly” but I never believed it until I actually got to work with this new hardware. It is truly amazing and it as brought the joy back into my work with virtual machine test labs.
Let us begin our journey into the configuration of the TMG firewall and clients to support outbound SSL inspection. The first step is to create a Web Access Policy.
Create the Web Access Policy
Web Access Policy is something new in the TMG firewall. When you use the Web Access Policy wizard, you are given the opportunity to do almost all the configuration you need to allow and control outbound access to HTTP and HTTPS (SSL) sites. The Web Access Policy is very handy and makes the TMG firewall very easy to use, even for those who have not used it or the ISA firewall in the past.
The first step is to open the TMG firewall console and expand the Forefront TMG node on the top of the list in the left pane of the console. Then, click on the Web Access Policy node as seen in the figure below.
On the right hand side of the console pane, click the Tasks tab in the Task Pane. In the Access Policy Tasks heading, click the Configure Web Access Policy link (as seen in Figure 3 below).
This brings up the Welcome to the Web Access Policy Wizard. Click Next to begin the process of configuring a Web Access Policy.
On the Web Access Policy Type page, you are given two options:
- Create a simple Web access policy for all the clients in my organization
- Create customized Web access policies for user, groups and computers
Since we are focusing on outbound SSL inspection in this article, we are going to choose the simpler of the two options (which is the Create a simple Web access policy for all the clients in my organization option). What this will do is create a single policy that applies to all users, and does not go into a detailed/granular/per user/per group/per site type of policy configuration. The second option on the other hand allows you to perform all the above mentioned options.
In a future article we will get into the details of how to use the Web Access Policy wizard and explore the second option that allows you to create much more granular access policies. I am not sure how I feel about it yet since I think it might introduce complexities that make creating granular policies more difficult. I am going to reserve my judgment to when I have more experience with its implementation in the Beta 3 version of the product.
Moving on… you should now select the Create a simple Web access policy for all the clients in my organization option and click next.
On the Blocking Web Access by URL Categories page, you have a chance to configure the URL filtering feature included in the TMG firewall. This is a subscription feature, so you will need to pay for a subscription in order to use it (although I suspect there will be a short trial subscription period in order to test it in your environment).
There are two options here:
- Baseline (use the recommend minimum URL categories)
- Custom (I will select URL categories)
Since we are really only interested in outbound SSL inspection at this time, let us just select the easy option (Baseline). This will configure the policy to block a basic set of sites that Microsoft has deemed that most people do not want to allow outbound access to. The Custom option would allow you to select the categories you want to block. In a future article, we will go through the details of the URL filtering options available in the TMG firewall.
Select the Baseline (use the recommended URL categories) option and click Next.
On the Block Web Destinations page, you will see the categories that were selected for you, as part of the baseline blocked categories set.
Keep note of the fact that the rule will be named Blocked Web Destinations, and that you will be able to create exceptions on the next page of the wizard.
Click Next to move to the next page.
On the Blocked Web Destinations Exceptions page you can make exceptions for users who you do not want to block access to the forbidden categories. Typically, this will be administrators and CxO types. Since we are interested only in the outbound SSL inspection feature in this article, we will not get into the details of creating exceptions to URL filtering at this time, but I will make sure to cover this in a future article.
On the Malware Inspection Settings page you are given the following options:
- Do not inspect Web content requested from the Internet
- Inspect Web content required from the Internet. There is also a sub option for this one: Block encrypted archives
This page is all about inspecting content for malware. Like URL filtering, you are going to need a license to benefit from the malware inspection features but, I am sure that there will be a short term license that you will be able to use when testing the feature. Even though we are primarily interested in outbound SSL inspection, we want to enable the malware inspection feature. The reason for this is that one of our main goals for outbound SSL inspection is to make sure that malware contained within SSL tunnels can be blocked. To do that, malware inspection needs to be enabled.
Select the Inspect Web content requested from the Internet option and also select the block encrypted archives option too. That will allow the TMG firewall to inspect the archives and remove malware contained within them.
Now we are getting to the pages that we are most interested in. On the Web Access to HTTPS Sites page, you are given the following options:
- Allow users access to Web sites using HTTPS: When you enable this option, users are allowed access SSL sites and also allow outbound SSL connections. When you enable this option, you need to pick one of three sub-options;
Inspect HTTPS traffic and validate HTTPS site certificates. HTTPS traffic is inspected using protection mechanisms configured on Forefront TMG. This option turns on the outbound SSL inspection and exposes the contents to the URL filtering and malware inspection functions. In addition, the TMG firewall will validate the server certificate presented to the firewall by the destination server. If the certificate validation process fails, the connection attempt will fail.
Do not inspect HTTPS traffic, but validate the HTTPS site certificate. Block HTTPS traffic if the certificate is not valid. When you select this option, the SSL traffic is not subject to outbound SSL inspection, but certificate validation is performed, so that if the server certificate presented to the firewall cannot be validated, the connection will be refused
Do not inspect HTTPS traffic and do not validate the HTTPS site certificate. All HTTPS traffic is allowed. This option removed outbound SSL inspection and SSL certificate validation. When you select this option, you reduce the security for SSL connection down to what you would have with a typical “hardware” firewall
- Do not allow users access to Web sites using HTTPS. When you select this option, no rule is created to allow outbound connections using SSL. While this is more secure than allowing uninspected SSL connections, there might be some complaints among your users, and this could have a negative impact on user productivity.
In this example we will select the Allow users access to Web sites using HTTPS and Inspection HTTPS traffic and validate HTTPS site certificates. HTTPS traffic is inspected using protection mechanism configured on the Forefront TMG. This enables us to perform outbound SSL inspection as well as server certificate validation.
On the HTTP Inspection Preferences page, you have to make two choices. The first choice you make is whether or not you want to let your users know that you are inspecting their SSL sessions, and the second choice relates to the certificate that will be used to sign the certificates that impersonate the destination Web sites.
On this page we have two sets of options:
- Do not notify users that outbound HTTPS traffic is being inspected. When you select this option, users will not be notified that their SSL sessions are being inspected. If you select this option, you should make sure that you remind users on a periodic basis, either through email or other communications, that SSL sessions are inspected and that they should be aware that passwords might be exposed in the URLs that they visit. This means they should avoid all personal business using corporate computers. Indeed, this is a good general policy and violations should not be tolerated.
- Notify users that outbound HTTPS traffic is being inspected. When you select this option, users will be notified by a little balloon that appears in the system tray when they connect to SSL sites. However, to enable this feature, you will need to install the TMG firewall client on the client systems. There are a lot of reasons to install the firewall client, and this provides just another one. I highly recommend that you go with this option when using outbound SSL inspection.
The other two options are related to the certificate that will be used to sign the SSL certificates the TMG firewall creates to impersonate the destination SSL sites:
- Use a certificate automatically generated by Forefront TMG. This option enables the TMG firewall to create its own certificate.
- Use a custom certificate, this option lets you customize the automatically generated certificate or select an alternate certificate. This option allows you to customize the certificate created by the TMG firewall, or if you don’t want the TMG firewall to create the certificate, you can use your own certificate and the TMG firewall will use it and deploy it for you.
In this example we are going to select the Notify users that outbound HTTPS traffic is being inspected and use a certificate automatically generated by Forefront TMG. However, before clicking next, check out the next screen shot to see what the interface looks like when you select the Use a custom certificate option.
After viewing those options, go back to select these and click Next.
When you choose the Use a custom certificate option, you see that you have two choices:
- Forefront TMG will generate the certificate automatically, with these details. This option allows the TMG firewall to generate the CA certificate that will sign the impersonate Web site certificates. There are three sub-options here:
Trusted certificate Authority name: Enter the name of the CA you want to appear on the certificate. TMG enters a default name for you.
Never. By default, TMG sets this certificate to never expire, which has a date of 1/1/2049.
Expiration data. Here you can set a custom expiration date for the CA certificate if you do not want it to ever expire.
Issuer statement. By default, TMG does not include an issuer statement on the CA certificate. You can enter one here if you like.
- Import an existing certificate. This option lets you use your organization’s existing CA to generate a certificate. When you select this option, you can use your own PKI to generate a certificate that will be used to sign the impersonate Web site certificates. When you select this option, you have the following options:
Certificate Location. Here you can enter the path or click the Browse button to inform the TMG firewall of the location of the certificate you want to use.
Certificate file password. If the certificate file has a password, you’ll need to enter that here.
In this example we are not using the options on this page.
On the Certificate Deployment Preferences page you are presented with options in order to deploying the CA certificate used to sign the impersonated certificates. You have the option of letting the TMG firewall deploy the certificates through Active Directory for you, or if you’re not working in an Active Directory environment (definitely not recommended), then you can export the certificate created by the firewall and deploy it manually.
In this example we will select the Automatically deploy the trusted root certificate using Active Directory (recommended) option. When you select that option, you need to enter a Domain administrator username and Domain administrator password. This information will be used to deploy the certificate using Active Directory.
On the Web Cache Configuration page, you can configure Web caching on the firewall. In this example we are interested in the outbound SSL inspection feature, so we would not enable Web caching in this scenario. However, it is important to mention at this point that it is possible to cache the SSL content if you enable that option in a cache rule. However, the default setting is not to cache SSL responses for outbound connections.
Do not select the Enable Web caching option. Click Next.
On the Verifying Inspection and Protection Features page, you can verify inspection and protection features that are currently enabled for the Web Access Policy that you are creating. Make sure that both Enable URL filtering and Enable HTTPS inspection are enabled.
This brings you to the end of the Web Access Policy wizard. Read the details of the policy you created and click Finish.
After clicking Finish, you will see a command prompt window appear. This command prompt window is running the certutil utility to deploy the certificate into the Active Directory DS store. If you are acquainted with the details of how to use certutil (I am not), then the figure below might be helpful in explaining what is going on in the background. There is a certain degree of “black box” feeling here, as there is no documentation on how the certificate is deployed, or how to manage the certificates that are deployed through this mechanism. We will revisit this sticky subject in a little bit.
Click Apply to apply the changes to firewall policy. In the Configuration Change Description dialog box, you can enter a reason for the change if you like. You also have the option to export current policy in case you want to revert to the previous configuration. Or, if you never want to see this dialog box again, you can put a checkmark in the Do not show this prompt again checkbox. Do not worry. If you want to see it again, you can re-enable it later.
Click Apply here to save the changes to firewall policy. Click OK in the Saving Configuration Changes dialog box.
In this, part one of this two part series on outbound SSL inspection, we took a look at why outbound SSL inspection is important and then went into the details of how to create a Web Access Policy that enables outbound SSL inspection. In the second part of this series, we will look at the details of the configuration and then test it to see if it actually works. See you then! –Tom.
If you would like to read the next part of this article series please go to Outbound SSL Inspection with TMG Firewalls (Part 2).