Best Practices: Giving your SSL Client some Context

Version 5

     

    Introduction

     

    The Web Gateway is frequently deployed in environments where HTTPS traffic (HTTP traffic within an SSL tunnel) must be passed through the Web Gateway.  When a browser makes an HTTPS request, it expects a proper SSL handshake to occur before content is passed within the tunnel.  For customers using the SSL Scanner, there is a rule set within the Rule Set Library that allows the Web Gateway to perform certificate verification, content inspection, etc.  The ‘SSL Scanner’ rule set properly handles the SSL handshake with the client as well.

     

    For customers who are not using the SSL Scanner, there are still cases where the Web Gateway may need to ‘interact’ with the SSL connection.  One example is if we need to issue a block page to an HTTPS request.  If the Web Gateway is not configured to interact with the SSL connection, it will issue an HTTP block page in response to that HTTPS browser request.  As a result, your browser will display an error, or a “Page Cannot Be Displayed”.

     

    IF YOU EXPECT THE WEB GATEWAY TO DO ANYTHING OTHER THAN SIMPLY ALLOW HTTPS TRAFFIC (i.e. redirect, block and display a block page, etc), YOU MUST HAVE THE SSL CLIENT CONTEXT ENABLED.

     

    We will discuss how to handle this situation.  Let's begin by going through some background information!

     

     

    HTTPS through a proxy

     

    First, let’s quickly review how an SSL Tunnel is established, when a proxy is in place.  In the below example, the proxy will not be filtering any traffic, just facilitating the connection.  Take a look at the screenshot below:

     

    VISIOssl-no-filtering-final.png

     

    1. First, the client establishes a connection to the proxy.
    2. Once the connection is established, the client sends the ‘Client Hello’ message.
    3. The Web Gateway passes that ‘Client Hello’ on to the external host, on behalf of the client.  The external host responds with a ‘Server Hello’, which the MWG forwards on to the client.
    4. As a part of the ‘Server Hello’ process, the external Web Server’s certificate is sent to the client, along with a ‘Server Hello Done’ message.
    5. The client sends along a client key, as well as Cipher Spec information.
    6. The external server sends back its own Cipher Spec info to meet client’s requirements, the tunnel is established.
    7. Traffic can now be sent along to the external host inside of the encrypted tunnel.

     

    We can see this exchange happen ‘on the wire’ as well.  See below Packet Trace (tcpdump) output (as captured on the Web Gateway), viewed in the program Wireshark:

     

    INFORMATION FOR WIRESHARK IMAGE BELOW: Client IP: 10.10.89.1 – Web Gateway IP: 10.10.89.117 – External Server IP: 194.77.103.20

    screenshot-showing-wireshark-no-filtering.png

     

     

    Browser Requirements and Behavior

     

    When a browser makes a request for an HTTPS site, the browser expects that a web server certificate be provided in the response from the web server.  Among some other things, the browser expects the following of the web server certificate:

     

    • The ‘Common Name’ of the certificate presented matches the name typed in the browser address bar
    • The web server certificate is signed by a Certificate Authority the browser trusts

     

    We can see that the certificate (from the external server) provided to the browser in the above example, meets those requirements:

     

    certificate-presented-unfiltered-with-cert-path.png

     

    **If the Web Gateway needs to send something to the client (who made an HTTPS request), it MUST sent a certificate, and the browser must trust that certificate (meeting requirements A and B above)**

     

     

    Examples of Web Gateway “Interaction” when handling HTTPS sites

     

    If the Web Gateway needs to ‘interact’ with an SSL connection for any reason, special consideration must be placed on rules and location.  One common example of ‘interaction’ is clearly SSL inspection.  However for users who are NOT using SSL inspection, there are three other very common types of SSL interaction:

     

    HTTPS URL Blocked

     

    If the client makes an HTTPS request for a site the Web Gateway’s policy determines should be blocked, the Web Gateway will issue a block page.  In order for that block page to be presented to the client (remember that the client expects a proper SSL handshake when it makes an HTTPS request), the Web Gateway must interact with that SSL Connection to be able to present the block page inside an SSL tunnel.

     

    To do so, the Web Gateway issues a web server certificate (with common name matching the request from the browser, and signed by a certificate authority loaded on the box). It uses this web server certificate to establish the SSL connection with the client, in order to present the block page.

     

    See the screenshot below, and note the difference in the certificate presented:

     

    screenshot-showing-actual-cert-presented-when-mwg-blocks.png

     

     

     

    Note the ‘Issuer’ of the certificate.  This is a Certificate Authority that is configured on the Web Gateway appliance:

     

    screenshot-CA-generated-on-appliance.png

     

     

     

    In the event that the Web Gateway policies determine a request should be blocked, the Web Gateway will never establish a connection to the external web server.  Take a look at the SSL handshake that occurs in this case:

     

    VISIOssl-MWG-filtering.png

     

     

     

    As noted above, the Web Gateway never makes a connection to the external host.  We can see this behavior in the below packet trace (taken on the Web Gateway, viewed within Wireshark):

     

    INFORMATION FOR WIRESHARK IMAGE BELOW: Client IP: 10.10.89.1 – Web Gateway IP: 10.10.89.117

    screenshot-wireshark-mwg-filtering.png

     

    Connection error when browsing to HTTPS site

     

    In the event of an upstream connection error (which could be a DNS failure, upstream tcp connection failure, etc.), the Web Gateway will also attempt to display a block page.  Just as in the example for URL blocked, the Web Gateway must interact with that SSL connection between the client and itself.

    To learn more about potential causes for connection errors, see this community article: https://community.mcafee.com/docs/DOC-4927

    Web Gateway Redirection

     

    Redirection as an action is more common in transparent deployments, but not exclusive to them.  A common example is if the client browser needs to be redirected to the authentication server.  In order to provide that redirection to the client, we need to issue an HTTP ‘302 – redirect’ response.  That response must be inside of the SSL tunnel.  Thus, we must interact with that SSL connection to issue the response.

     

     

    How to handle HTTPS connections through Web Gateway

     

    Now that we have discussed the background information, let’s go over the configuration requirements on the Web Gateway:

     

    1. A Certificate Authority must be configured or imported on the Web Gateway.
    2. The event “Enable SSL Client Context with CA” must be called.
    3. The event should be placed above all of your existing rules in your policy.

     

     

    Certificate Authorities - some background

     

    A Web server certificate is a certificate provided to a client, by a specific, distinct, web host, for the purpose of establishing an SSL tunnel.  That certificate is ‘signed’ by a Certificate Authority.

     

    The web server certificate is for a specific host (i.e. contentsecurity.mcafee.com).  This web server certificate cannot be used for another host (i.e. supersecureportal.sitename.com).

     

    Remember the client browser requirements above state that the certificate’s common name must match the name typed in the browser’s address bar.  Since the Web Gateway must be able to dynamically create a web server certificate on the fly, for possibly any requested URL host, a ‘Certificate Authority’ must be configured on the appliance.

     

    You will NOT be able to configure a ‘public’ Certificate Authority (Verisgn, Thawte, EnTrust, etc.) on the appliance, since you will not be able to obtain a ‘Certificate Authority’ from those public CAs and use it for our purposes.  It is the ability to ‘dynamically’ sign web server certificates that is not available to most organizations by the publically trusted authorities.  (Those authorities will sign and provide ‘a’ specific web server certificate, but not a CA certificate that allows signing of other certs) You will NOT be able to purchase a Certificate Authority from a public authority!!

     

     

    Configuring a Certificate Authority on McAfee Web Gateway

     

    You have two options to configure a Certificate Authority on the appliance:

     

    First, you can generate a Certificate Authority directly within the user interface.  Within the Web Gateway product guide, navigate to ‘Chapter 10 -> Web Filtering -> SSL Scanning -> Replace the default root certificate authority -> Create a root certificate Authority’.  Once this CA is generated, you can export that cert and push it out to your client workstations so they can trust it.

     

    Second, you can import a local certificate authority onto the appliance.  Many organizations use a local certificate authority (such as Microsoft’s CA) to sign their internal certs, and usually these are already trusted by domain workstations. Within the Web Gateway product guide, navigate to ‘Chapter 10 -> Web Filtering -> SSL Scanning -> Replace the default root certificate authority -> Import a root certificate Authority’.   For more information about generating the CA from your Microsoft CA, use KB75037 (http://mcaf.ee/wgcbf).

     

     

    The “SSL Client Context with CA” event - some background

     

    As mentioned above, if the Web Gateway must ‘interact’ with an SSL connection (i.e. if you would like to send any HTTPS traffic through the Web Gateway), the Web Gateway must have the ability to issue a web server certificate to the client, dynamically created and signed by the Certificate Authority configured on the appliance (see above).

     

    This functionality is provided by the ‘Event’ called “Enable SSL Client Context with CA”:

     

    screenshot-enable-ssl-client-context-with-CA.png

     

     

    You can see that the event “Enable SSL Client Context with CA” references a setting container (in this case, the ‘Default CA’ container).  This setting container references a certificate authority that must be configured on the Web Gateway appliance.

     

    **Pro tip: You can have multiple Certificate Authorities installed, in separate setting containers:

     

    screenshot-multiple-CAs.png

     

    How to use the “SSL Client Context with CA” event

     

    If you are NOT using the SSL Scanner rule set, then the event “Enable SSL Client Context with CA” should be placed in a rule, within the top-most rule set of your policy:

     

    mbo-screenshot-showing-finalSSL-ClientContext-rule-set.png

     

     

    Here’s how to create it:

     

    First, click to ‘Add’ a new Top Level Rule Set, and create one that looks like below:

     

    mbo-screenshot-showing-final-top-level-rule-set.png

     

     

     

    Next, after placing the new rule set ‘Enable SSL Client Context for deployments without SSL Scanning’ as the top most rule set, create a rule within that rule set like below:

     

    mbo-screenshot-showing-SSL-client-context-rule.png

     

    **When selecting the event, be sure you select Enable SSL Client Context With CA.  Do NOT use the event ‘Enable SSL Client Context without CA.  This is to be used in very specific deployments.  Contact Technical Support with questions.

     

    Finally, when selecting the “Setting” container, be sure you select the container you used when configuring the Certificate Authority on the appliance, as in the prior instructions above.

     

     

    Conclusion

     

    Above, we discussed some background information about accessing HTTPS sites through the Web Gateway.  We found that there are instances where we must have rules to 'handle' these HTTPS sites, even if full SSL inspection is not used. With some simple rule placement, and the use of the 'Enable SSL Client Context with CA' event, users can have a problem-free experience accessing HTTPS sites!