03 June 2011

TMG HTTPS Inspection Part I - Planning

Why is it needed

By default outbound HTTPS traffic is not inspected by TMG.  This is because of the SSL tunnel that encapsulates all the traffic.  This is great for keeping sessions private between the client and the server.  The problem now exists that you have a bi -direction data stream in and out of your corporate network that you are no longer inspecting for malware etc.  It also allows users to potentially bypass corporate policies by tunneling traffic through the SSL channel, such as peer to peer or proxy avoidance sites.

To enable TMG to inspect the HTTPS traffic you need to configure HTTPS inspection under the Web Access Policy.

How it works

TMG has to become a "man in the middle" between the client and the server.  This is not different from what it is for normal HTTP traffic.  The HTTPS / SSL differences, in sequence, are:

  1. TMG etablishes the SSL tunnel with the server and validates the site and certificate.
  2. TMG then copies the certificate details and issues it's own corresponding certificate for the client.
  3. TMG then uses this certificate and establishes a secondary secure channel to the client.

Essentially you now have two SSL tunnels as opposed to just one that goes all the way through.

Certificate Validation
As part of enhancing the SSL security TMG can also be configured to do additional Certificate Validation.  This can be configured to check for some or all of the following criteria:


  • Block Expired Certificates after n days
  • Block server certificates that are not yet valid
  • Check for server certificate revocation (crl)


These are things that can normally be overridden by client during browsing.  These checks prevent those from getting to the client and having to make the decision.

Things to consider when planning
Whenever additional security is added you run the risk of additional impact on your users.  There are a few drawback that can be resolved, but one should be aware of them.

  • TMG has to becomes a trusted certificate authority for all the client machines
  • Extended Validation (EV) is not supported as EV, you would have to exclude these sites to get the green bar
  • External SSTP (Secure Socket Tunneling Protocol VPN) is not supported unless they are manually exluded
  • Clients must belong to the same domain as TMG
  • Self signed certificates are not supported, unless excluded
  • Not all browses use the machine certificate store EG Firefox certificate store needs to be configured separate to the machine
Privacy
Unless a user has the TMG client installed and the HTTPS inspection is set to "Notify users that their HTTPS traffic is being inspected" a user will not know that this is the case.  Unless they check every certificate to see who the CA is.  Because users expect SSL session to be private and secure you might want to or have to notify your users of this.  


Exclusions
Almost all of the potential problem above can be mitigated or worked around by buildiong proper exclusion lists.   Exclusion can be base done based on the Source and /or  Destination.  You can for example exclude all HR computers, or you can exlude all sites in the "Financial" url categories.

Conclusion
Depending on circumstances HTTPS inspection may or may not be a priority for your environement.  If you have to implement it you need to follow the steps to make it a smooth transition.  If not, all HTTPS traffic will be compromised...

3 comments:

Anonymous said...

Before deploying HTTPSi, I would also recommend installing TMG SP1 Update 1 Rollup 3 as this includes quite a few HTTPSi fixes.

Etienne Liebetrau said...

Yes thanks for the tip, of course you should always keep TMG up to date. In this update there are 4 specific HTTPSi fixes. For more info see

http://support.microsoft.com/kb/2498770

You can request and download from:

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2498770&kbln=en-us

Kurt Reynolds said...

Very interesting article, I have a question. We have a TMG gateway between our users and our Web server. What we are finding is that unauthenicated users can ask TMG for say https://mysite/getmystuff which is an invalid URL, the problem is that TMG is somehow pinging the webserver and causing the webserver to throw an exception (404 error) and it looks like the unauthenicated user was able to hit the server. Why is TMG asking the webserver for the URL if the user is not authenicated?

Post a Comment