If you would like to read the first part in this article series please go to Outbound SSL Inspection with TMG Firewalls (Part 1).
In part one of this two part series on outbound SSL inspection with the TMG firewall, we covered the importance of outbound SSL inspection and its critical role in network security. After that, we went through the Web Access Policy Wizard to create a Web access policy that allowed outbound connections to HTTP and HTTPS sites. In this, part 2 (and the final part of this series), we will look at the outbound SSL inspection configuration in more detail and then test the setup to see if it actually works.
Examine the Outbound SSL Inspection Configuration
Now that the policy is created, let us take a look at what happened. If you look in the middle pane of the TMG firewall console, you will see that a new firewall rule called Blocked Web Destinations has been created. This appears as one of the rules in the Web Access Policy Group. Now, you might be wondering about this “group”. In the past we have always wanted to be able to group our rules, but the ISA firewalls of the past wouldn’t allow us to do that. Guess what? You can group your rules with TMG firewalls. Nice. In this rule you can see that it applies to all users from the default Internal network, and the destinations are noted in the “To” column, with the “To” column listing the URL filtering groups that we want to block access to.
Notice the section above the firewall policy – the Web Access Settings section. Here you will find entries for:
- Web Proxy
- HTTP Compression
- Malware Inspection
- Web Caching
- HTTPS Inspection
This provides a nice “one stop shop” for all of your Web proxy connectivity options. We are most interested in the HTTPS Inspection settings at this time, so click the Enabled link next to where it says HTTPS Inspection.
This brings up the HTTPS Outbound Inspection dialog box. On the General tab, you can see a number of options.
The Enable inspection of outbound HTTPS traffic option is enabled because we configured this option in the Web Access Policy wizard. It also includes our selection Validate the certificate and inspect outbound traffic.
In the Certificate Inspection Settings frame, you see the options to Use a self-signed certificate generated by Forefront TMG and Import an existing trusted CA, similar to what we saw in the Web Access Policy Wizard.
Click on the Trusted Root Certificate Options button.
This brings up the Certificate Deployment Options dialog box. Here you can:
- View Certificate Details; This allows you to see the certificate used by the TMG firewall
- Automatic Deployment; Configure automatic deployment into the mysterious “DS” certificate store (more on this later)
- Export to File; Here you can export the certificate created by TMG to a file so that you can configure non-domain members to trust the signing certificate in order for the machines to work with outbound SSL inspection. When you choose this option, you have to manually import the certificate into the non-domain member computers Trusted Root Certification Authorities machine certificate store; not its user or service certificate store. You can also use this option if you want to deploy the certificate using standard Group Policy based autoenrollment, instead of it disappearing into the mysterious “DS” rabbit hole.
The Certificate dialog box appears when you click the View Certificate Details button. Note the Issued To and Issued by information and the certificate validity dates.
Click on the Destination Exceptions tab. Here you can exclude sites from HTTPS inspection and specify whether HTTPS certificates for those sites should be validated. Notice that these are two separate options, in that you can configure sites to not be inspected, but require certificate validation, and vice versa.
There is a default group called Sites Exempt from HTTPS Inspection that you can add too, if you like. If you click on the Site and click the Edit button, you will see the Sites Exempts from HTTPS Inspection Properties dialog box. This is actually just a Domain Name Set that can be used in any of your firewall rules.
The default entries in this Domain Name Set are:
Again, because this is a conventional Domain Name Set, you can add your own entries to this list.
Notice the Validation button in the HTTPS Outbound Inspection dialog box. When you click on the site, you can click the Validation button to enable or disable validation for the site of interest. You can see in the graphic that for the Sites Exempt from HTTPS Inspection site, that the Certificates column lists No Validation.
On the Source Exceptions tab, you can set exceptions so that certain clients are exempted from HTTPS inspection. I should note that you can set exceptions only for Computers and Computer Sets. You ca not do this on a per-user or per-group basis, which would have been pretty nice.
On the Certificate Validation tab you can set the certificate validation policy that is applied to all clients making SSL requests through the TMG firewall. There are three options on this tab, none of which were exposed when we went through the Web Access Policy Wizard. These are:
- Block expired certificate after (days): This option allows you to configure how many days a server certificate can be expired before the site is blocked (that is to say, fails the validation check). The default setting is 15 days, but you are free to change this if you are more (or less) trusting than Microsoft.
- Block server certificates that are not yet valid: If the certificate returned from the Web server is not yet valid, then the connection will be dropped.
- Check for server certificate revocation: When this is enabled, if the server certificate has been revoked, then the connection will be dropped. However, there is no documentation at this time what the behavior will be if CRL checking itself fails due to the CRL not being available. I did not test this yet, so I will have to let you know what I encounter such a situation in the future.
The last tab on the HTTPS Outbound Inspection page is the Client Notification tab. Here you have one option: to enable or disable user notification by checking or unchecking the Notify users that HTTPS inspection is applied checkbox.
Now, let us get back to the subject of the self signed CA certificate created by the TMG firewall. For most of us who are not Active Directory or PKI experts, we are used to the idea that you can use Group Policy and autoenrollment to deploy certificates into client systems’ Trusted Root Certification Authorities. We have been doing this for years. It works great, you can see the certificates in the Group Policy Management console, and you can see the certificate in the Certificates MMC on the domain controllers. All is good, manageable and transparent.
When we change focus to TMG and how it deploys the CA certificate, things get a lot more muddy, dark, “un”-transparent and downright scary. Why? Because if you look in Group Policy to see the certificate being deployed using autoenrollment, you would not see it there. If you look in the Certificates MMC on the domain controller you would not find it there either.
So where will you find it? I’m still not sure! Jim Harrison and David Cross from the ISA/TMG team half pointed me in the right direction by providing links to articles that peripherally cover this subject, but none of these articles really answered my question “how to I manage the certificate deployed by the TMG computer for outbound SSL inspection?”.
What I was able to find out after a few hours of trial and error was that if you use the certutil utility, you can display the certificate. The command is:
Certutil –enterprise –viewstore
Do not ask me what the –enterprise or –viewstore switches mean, because the certutil documentation is about as clear as mud. However, if you do run this command, you will see what appears in the figure below. Actually, what you will see when you run the command is the View Certificate Store dialog box, which is a dialog box I have never seen before. I found the title bar on the dialog box interesting. Yes, I can view the certificate store. But what certificate store? And what makes this certificate store so special that it has no other certificates in it other than the one I have deployed the TMG certificate into?
I admit, if you are a PKI or Active Directory jockey, you probably think these are stupid questions and that I should know the answers. But, I am just a TMG firewall guy who knows enough about PKI and Active Directory to make it through the day. I have been making it through the day for the last 10 years without encountering this View Certificate Store dialog box, so it must not be that important for day to day operations of Active Directory or PKI. Nevertheless, it would be cool if someone could explain where this certificate is stored, how autoenrollment works for this certificate without the help of group policy, and how we delete this certificate if we do not want to use it anymore.
The figure below shows the Certificates MMC on the Vista client computer. Notice that the certificate does appear in the Trusted Root Certification Authorities certificate store, so we know that which distribution mechanism being used is working. You need the TMG certificate in each of the computers’ Trusted Root Certification Authorities machine certificate store so that they trust the certificates and the TMG firewall generate to impersonate the SSL sites the clients connect to. This is something to keep in mind when troubleshooting outbound SSL inspection problems – if it is not working, check the MMC console on the clients first.
Install the Firewall Client on the Client Computer
The TMG firewall client is required for client notifications. I am not going to go into the details of the ways you can deploy the TMG firewall client, as you have a number of manual and automated options available to you. Instead, I just want to let you know where you can find the TMG client application. As you can see in the figure below, the client application is either on the install DVD (does anyone install from DVD anymore?) or from the installation folder tree. The folder is the client folder in the installation hierarchy and the name of the file is MS_FWS.msi.
Access SSL Sites and Observe SSL Inspection and Detection
Now let us see what happens when the client tries to connect to an SSL site. On the Vista SP1 client, I’ll go to my hotmail account. After logging on, a balloon pops up that looks like the figure below. The text of the balloon is as follows:
“iexplore.exe initiated a secure connection to login.live.com. The connection is being inspected for malware detection. Click this balloon to manage how Outbound Inspection notifications are shown”.
That is some pretty interesting stuff! Certainly should get the attention of your users.
Once users get used to the idea that they’re being watched, they might want to calm down the balloon at bit. If they double click on the Firewall client icon and click on the Secure Connection Inspection tab, they have a couple of options.
- Notify me when content send [sic] to secure Web sites are inspected. Notice a little beta bug in the text here, which I am sure will be fixed by RTM. This option is enabled by default. If the user does not want to be notified, he can remove the checkmark from this checkbox. However, since the policy on the TMG firewall is to notify users, I am not sure yet if after the Firewall client configuration is refreshed, the checkmark will be automatically re-enabled. I hope so, since policy should be controlled by the admin, not the user.
- Notification Exceptions. By default, users are only reminded about inspection for a specific site once per hour. However, each time they go to a new SSL site, they will be reminded that they are being inspected at that new SSL site. But, they would not be reminded again about that site for one hour. However, the users are given the option of not being notified ever for the sites they choose. I do not know if this is a good idea, because it is letting users control a policy that can potentially put your business at risk, as you can imagine the litigious user say “I forgot that I told it not to remind me. You should not have given me that option!”
How about malware detection over an SSL link? I put together a Web server on the lab network and populated it with an SSL site that had the eicar virus string in a text file. After connecting to the site and trying to download the text file with eicar virus string, I got this on my Vista client:
Nice to see that malware protection does indeed work over an SSL link! So much for malware authors trying to leverage SSL connections to download their evil doings to your machines. Well, it will still work for them if they do not have a TMG firewall (or an ISA firewall with ClearTunnel installed).
After connecting to the Web site and having the malware blocked, what next? Let’s check the Alerts tab in the TMG firewall console. There is an alert definition that can be configured to inform you that malware was detected, but it is not enabled by default. I enabled the alert in advance so that it would be triggered after blocking the malware.
The figure below shows the alert Malware Inspection Filter Detected Malware. In the details pane is says The Malware Inspection Filter detected malware and either removed it or blocked the message. See the Web Proxy log for details. Hmmm… It would have been nice to have more information about the malware in the alert, looks like we will have to check the Web Proxy log to see details.
Go to the Logging & Reports node in the TMG firewall console and click the Logging tab. I set the Log Time for the Last Hour and configured the Malware Inspection field for Blocked. The figure below shows the Web Proxy log file entry for the blocked connection. The detail pane shows the URL that triggered the block and the name of the file is contained in the URL. Notice that this was indeed malware detected inside an SSL session, as the URL is https://www.clickme.com/badfile.txt.
However, the details didn’t give information about the name of the malware. Let’s scroll down to the right in the fields in the viewer and see if we can find that information. There it is in the Threat Name field. Notice there is also a Threat Level field that gives an assessment of the level of the threat.
Finally, let’s finish up with a view of the communications that take place between the TMG firewall and the client. In order for the Firewall client to let the user know that the SSL session is being inspected, the TMG firewall needs to communicate with the Firewall client application. This is something new with the TMG firewall, since with previous versions of the firewall the Firewall client communications were always initiated in one way – from the client to the firewall. With the TMG Firewall client, communications are bidirectional. The Firewall client initiates communications with the TMG firewall, and the TMG firewall initiate communications with the Firewall client.
The difference is in the protocols used. When the Firewall client connects to the TMG firewall, it uses TCP port 1745. In contrast, when the TMG firewall initiates a connection to the Firewall client, that connection starts on UDP port 1745.
The figure below shows the connections made from the TMG firewall to the Firewall client on the Vista SP1 client. Notice the protocol used is Microsoft Firewall Client (Notifications) and that there is a System Policy Rule that is automatically enabled when you enable notifications that allows outbound access from the Firewall to the clients.
In this two part series on outbound SSL inspection for the TMG firewall, we took a look at the topic of outbound SSL inspection and why it is so important that this be implemented on any network that wishes to meet a basic level of networks security. We then went through the configuration of the Web Access Policy that allows outbound access to HTTP and HTTPS connections. Outbound SSL inspection is enabled while running the Web Access Policy Wizard. After enabling outbound SSL inspection, we looked at the details of the configuration and wondered out loud about some of the mysteries of the CA certificate that’s deployed by the TMG firewall. We then finished up by establishing an outbound SSL connection so that we could see the notification balloon, and also see malware being blocked. The malware blockade was significant, since it was contained within an SSL tunnel.
If you would like to read the first part in this article series please go to Outbound SSL Inspection with TMG Firewalls (Part 1).