Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 8)

If you would like to read the other parts in this article series please go to:

Introduction

In previous installments of this series, we’ve gone into great depth and detail regarding web and server publishing rules in TMG 2010. This time, we continue our journey through the TMG firewall Web Publishing Rules by taking a look at some of the SSL settings that are available to you. Ever since the ISA firewall days, the ISA/TMG firewall has been known as one of the best when it comes to handling SSL connectivity from remote clients. This is because the TMG firewall is able to perform application layer inspection on SSL connections. In fact, the TMG firewall can perform SSL application layer inspection on both incoming and outgoing connections through the TMG firewall.

Deployment options

Before we take a look at some of the SSL related settings, though, let’s talk about the ways you can deploy an SSL Web Publishing Rule in the TMG firewall. There are essentially two basic ways that you can deploy an SSL Web Publishing Rule in the TMG firewall:  

  • SSL to SSL Bridging. In this type of SSL Web Publishing, the remote client establishes an SSL connection to the TMG firewall. The TMG firewall decrypts the connection and inspects the connection. Then the TMG firewall establishes a new SSL connection between itself and the published web server. The published web server responds to the TMG firewall’s request and sends the response to the TMG firewall. The TMG firewall again decrypts the connection, inspects it, and then encrypts it again and forwards the response to the client computer that made the initial request.
  • SSL to HTTP Bridging. This is sometimes referred to as “SSL offload” because the TMG firewall does the SSL heavy lifting on behalf of the published Web site. The remote client establishes an SSL connection with the published web server and the TMG firewall decrypts the connection and performs application layer inspection. Then the TMG firewall forwards the connection to the published web server over an unencrypted HTTP session. The published web server responds to the request by sending its response to the TMG firewall, where the TMG firewall performs application layer inspection on the response. Then the TMG firewall forwards the response to the client that made the original request over an SSL connection.

There is actually another way you can perform SSL publishing but we don’t see it used very often. In this scenario, you would have two TMG firewalls publishing the web site. The “upstream” firewall (the one that is closest to the Internet connection) accepts the SSL request from the remote client. The TMG firewall then decrypts the connection and inspects it. The TMG firewall then forwards the request to the “downstream” TMG firewall (the firewall that is closest to the published web site) using an SSL connection. The downstream TMG firewall decrypts the connection and inspects it. Finally, the downstream firewall forwards the connection to the published web server using SSL or HTTP. This is a high security configuration that you can use when your front-end TMG firewall is in a DMZ and you don’t want it to be a domain member, but you do want to enable authentication (pre-authentication) on the connections.

Note that in this configuration, you have an additional security option that you might want to consider. Since we’re talking about a high security situation, wouldn’t it be nice if you could require the upstream TMG firewall to authenticate to the downstream? The good news is that you can indeed do this. When using this kind of back-to-back TMG firewall combination, you can configure the downstream TMG firewall to require the upstream firewall to present a certificate for authentication. This makes for an even more secure setup.

To bridge or not to bridge?

There are different opinions regarding the use of SSL bridging. One opinion is that it’s great to use SSL to HTTP bridging because you can offload the processing overhead from the web server and put it on the TMG firewall. However, there is an opposing argument that states that the user has an implicit agreement with the published web server when establishing the SSL connection and that this agreement is broken when you deploy SSL to HTTP bridging.

There is no right or wrong answer to this; your best choice depends on your situation. It’s a business decision, but you should have a discussion with your security and legal teams regarding this issue in order to come to a consensus on what your best course of action might be.

Authentication options

Remember that there are two reasons that you would want to use SSL publishing:

  • Because you don’t want anyone to see the data that is moving over the SSL channel
  • Because you want to secure the authentication process

When you use SSL Web Publishing Rules, you have a number of authentication options available to you, as you can see in the figure below:


Figure 1

The options include:

  • Require all users to authenticate. This option requires that all users who use the Web Listener associated with the Web Publishing Rule must authenticate. All anonymous connections are dropped.
  • Require SSL client certificate. This option requires that all users who connect to the Web Publishing Rule using this Web Listener will need to present a client certificate. Of course, you can also choose to require additional authentication requirements, but if you select this option, the users must at least provide a client certificate.
  • SSL client certificate timeout (seconds): This is the amount of time that the client certificate will be considered valid before requiring the user to authenticate again. This doesn’t define the duration of the session, rather it controls the duration for the period of time for which the client won’t have to reauthenticate in the event that the client should become disconnected.
  • Allow client authentication over HTTP. This option is not related to an SSL publishing scenario because it pertains to enabling authentication over an non-SSL connection. There are few scenarios where you would do to this, however.
  • Validate credentials for every HTTP request. This option requires the client to reauthenticate for each request. This is secure but it’s very processor intensive and so is typically not done.
  • Validate credentials every (seconds). This allows you to set the interval of time in which the client needs to validate with the TMG firewall again. The default time period is 300 seconds (five minutes)

The TMG firewall must be able to trust any certificate provided by clients when you use client certificate authentication. The figure below shows the Client Certificate Trust List tab in the Advanced Authentication Options dialog box:


Figure 2

Note that you have two options here:

  • Accept any client certificate trusted by the Forefront TMG computer. This option will configure the TMG firewall to trust any certificate that chains to one of the certificates in the TMG firewall’s Trusted Root Certification Authorities store.
  • Only accept client certificates trusted by the Root Certification Authorities selected below. This option gives you more control over which CA(s) you want to trust when it comes to certificates delivered by client computers. This is the typical choice. You would select the CA that you trust for client certificates and then only the clients who have certificates that chain to the trusted CA will be able to successfully authenticate with the TMG firewall using a certificate.

Finally, you have the option to further restrict which certificates can be used by clients by using the options available on the Client Certificate Restrictions tab of the Advanced Authentication Options dialog box, as seen in the figure below:


Figure 3

Here you have the following options:

  • Accept the client certificate only if it matches at least one defined restriction. If you select this option, you can add restrictions that are to be placed on the client certificate. If the client certificate doesn’t meet the criteria you set, the client certificate will be rejected even if it is issued by a trusted CA.
  • Restriction name. Here you give a name to the restriction you want to set.
  • Certificate field. You have the choice of four fields on which you can set your restrictions: Issuer, Subject, Enhanced Key Usage and Extensions. If you select Issuer, Subnet or Extensions option, you will see the Value field become available. There you can enter the specific value or a value with a wildcard. If you select the Enhanced Key Usage option, then you will see the options in the Object ID section become available. There you have the choice to Match any OID in the selected certificate field or Match this OID in the selected certificate field and then you would enter the OID.

As you can see, when you enable SSL publishing and authentication, you have a number of options available to you. This is just one of the many reasons that we consider TMG firewall Web Publishing to be one of the most secure methods of web publishing available today.

Summary

In this article, we talked about some of the design options that are available to you when it comes to secure web publishing with the TMG 2010 firewall. We talked about the types of SSL bridging that can be used, and some of the advantages and disadvantages of each type. Then we took a look at some of the advanced authentication options that are available to you, which relate to SSL and certificates. And that just about wraps it up for the Web Publishing Rules. In the next article in this series, we will begin our journey through the Server Publishing Rules. See you then! –Deb.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top