whitepaper: mcafee web gateway mobile security

McAfee Web Gateway Mobile Security

Date: 13.07.2011

MWG Mobile security documentation Version: 2.2

Date: 2011-07-13

2011 of 22

This document is issued by McAfee GmbH, Germany

Table of Contents

Table of Contents 2

1 Introduction 3

2 What is needed for a working MWG infrastructure 3

3 General Description 4

4 What happens when a user sends a request from his mobile device? A step-by-step example. 5

5 A few words on “SecureToken” Cookies 6

6 A few words on the DNS setup 7

7 The configuration of MWG7 8

7.1 Configure the proxy port 9090 and the authentication server port 444 8 7.2 Import the rule set “Mobile Security for inbound traffic” 9

8 The rule set “Mobile Security for inbound traffic” 9

8.1 Rule set “Prevent Open Proxy” 9 8.2 Rule set “SSL Reverse Proxy” 10

9 Rule set “Authentication Server” 11

9.1 Authenticate Certificate 11 9.2 Create and send Certificate 13 9.3 Create and set a Cookie 13

10 Rule set “Reverse Proxy Feature” 14

10.1 Request Redirections 15 10.2 Authentication 15 10.3 Secure Reverse Proxy 16

11 What to configure on an iDevice if the client certificate is created by MWGs ruleset 17

12 Tips 21


Date: 2011-07-13

2011 of 22


1 Introduction

As more and more telecommuters and those who travel often enjoy the flexibility that mobile devices provide, the need to transfer company-sensitive data grows. Users need to be able to download files from the companies‟ intranets as well as upload data.

An important topic is therefore the secure connection between mobile devices and the corporate intranet.

A way to connect to the intranet is the usage of a VPN. The disadvantage of using this method is the variety of VPNs; some mobile devices do not support some VPNs, and in these cases, access to internal documents or internal web servers is not possible.

MWG 7.1.5 offers an alternative because it changes all HTTP requests to HTTPS requests, using a client certificate that can be imported into the browser - things that ensure compatibility to almost any browser one can think of and at least the same security a VPN could provide.

Additional advantages for using MWG:

- Flexibility of protecting the network based on ports (with help of iptables)

- MWG assists the user in creating a client certificate if none is available! The client certificate can then be downloaded and installed. If this feature is also available for mobile devices connecting from outside the companies‟ network, is completely up to the admin to decide.

- All additional security features of MWG like Antivirus or Media Type Detection can be used!

- Secure cookies are used to prevent browsers from repeating the client certificate authentication.

2 What is needed for a working MWG infrastructure

- We suggest the installation of MWG in a DMZ.

- To improve security on MWG, use “Network Protection” settings on MWG and configure the ports that should remain “open”. Dropping all other requests can ensure security. An example:


Date: 2011-07-13

2011 of 22


- MWG is installed as a reverse Proxy. Only the network ports needed for reverse proxying are open. By default, port 9090 is the port MWG is listening on, port 443 is the port SSL connections are established to; 444 is used to address MWG‟s internal authentication server. Port 4711 is used for the HTTP UI of MWG.

- Forwarding the client data can be done via routing or DNS. In the first case MWG has to be deployed in transparent router or bridge mode or a 3rd party routing device to forward the data, in the latter one DNS has to be manipulated. For more information on this please refer to chapter 6.

- All hosts that are not in the “allowed host” list, are blocked.

3 General Description

The ruleset “Mobile Security for Inbound Traffic” has to be imported to create the rules necessary for MWG to adapt to an environment in which mobile devices can authenticate.

To access the intranet the mobile devices will authenticate them self with a client certificate on an MWG7 reverse proxy. As soon as the devices are authenticated the proxy generates and sets a cookie. During a browser session this cookie is used for authentication. The cookie is important, because otherwise e.g. the Safari browser on iOS devices asks for a certificate for every connection.

Other topics addressed in the default ruleset “Mobile Security for inbound Traffic”

Each SSL-Connection which isn‟t a connection to an internal server or to the authentication server will be blocked.

Each non SSL-Connection is redirected to an internal proxy SSL-Connection.


Date: 2011-07-13

2011 of 22


At this connection the proxy checks for a valid cookie. If no valid cookie is available the proxy redirects to the authentication server.

The authentication server asks for the client certificate (As option: authenticates the user with another method, creates and sends the client certificate) creates and set the cookie and then redirects back to the internal SSL-Connection.

The internal SSL-Connection now connects to the original host (if this host is in the list of allowed hosts)

The complete data between the client and the proxy goes over the internal SSL-Connection.

4 What happens when a user sends a request from his mobile device? A step-by-step example.

The steps below happen if the client has a valid cookie (step 3 in the picture above)

1. Initial request to http://server1.exampledomain.com/index.html (port 80)

2. MWG redirects to https://server1-my--company-com-http-r.exampledomain.com/index.html (port 443)


Date: 2011-07-13

2011 of 22


3. The browser on the mobile device connects to this address. DNS points to MWG. MWG uses signed server certificate for *.exampledomain.com for this connection. Browser accepts connections.

4. MWG checks session cookie in this connection. If the cookie is not valid, redirect to authentication server https://authserverexampledomain.com:444/?url=<encodedURL>

5. If cookie is valid, MWG rewrites URL internally to original URL http://server1.exampledomain.com/index.html

6. MWG looks up server1.exampledomain.com in remapping list and eventually maps to a different host name

7. MWG checks the final host name against an allow list of supported hosts. If host is not on the list, the request is responded with an error message.

8. If allow list check succeeded, MWG connects to final host and proxies data between incoming HTTPS connection and outgoing HTTP connection.

5 A few words on “SecureToken” Cookies

As mentioned in the last chapters, cookies are used during the authentication process. The reason why it makes sense to use cookies: after the installation of the client certificate, the authentication is valid for the connection; as soon as the browser opens a new connection, the Safari browser would require interaction from the user and bring up some popup requiring the user to choose his client certificate.

http://server1.exampledomain.com/index.html


Date: 2011-07-13

2011 of 22


As a cookie is set, this does not happen anymore. While this process is already very secure (as it is based on client certificate authentication), we even enhanced the security by using the SecureToken property to create a cookie that is calculated based on the IP address, the timestamp (optional) and a hash algorithm based on a secret key.

When the browser opens a new connection, the validation of the cookie is done based on the same mechanism.

6 A few words on the DNS setup

As mentioned before, the DNS setup is an essential part of a working infrastructure.

1. Most “simple” setup: enter the servers of your internal network into the external DNS and have them direct to the IP address on which MWG Reverse Proxy is listening. The obvious disadvantage of this method is that companies might reveal too much information about their intranet. On the other hand, this method requires less effort when considering long-term administration. Here it is necessary for MWG to use a different internal DNS server that points to the intranet IPs instead to itself.

2. More “complicated” setup (as shown in the ruleset): Generate a wildcard DNS entry e.g. “*.exampledomain.com” that points to MWG. Here it is mandatory to create a mapping from the host names provided externally to the corresponding internal destinations. The advantage of this method is that internal hostnames are not propagated to external, but the disadvantages are that the mapping must be maintained which is an administrative effort and that server cookies might not


Date: 2011-07-13

2011 of 22


work, because the client believes that it is connected to a different domain and will not accept those cookies.

Another thing that might happen: if the internal server uses direct links or redirects to absolute URLs outside the internal network, then those links will not work with the ruleset provided. For this case it would be necessary to add a ruleset that would parse the response and trigger a reverse mapping.

7 The configuration of MWG7

7.1 Configure the proxy port 9090 and the authentication server port 444


Date: 2011-07-13

2011 of 22


7.2 Import the rule set “Mobile Security for inbound traffic”

8 The rule set “Mobile Security for inbound traffic”

8.1 Rule set “Prevent Open Proxy”

This rule set is executed during a HTTPS CONNECT command and blocks every HTTPS-Connection which isn‟t to the authentication server (Rule 1, 2) or to an internal MWG7 SSL-Connection (rule 3). The function SecureReverseProxy.GetDomain <Default1> „gets the Secure Reverse Proxy Domain‟ defined in the Default1 setting for the Secure Reverse Proxy filter.


Date: 2011-07-13

2011 of 22


8.2 Rule set “SSL Reverse Proxy”

This rule activates the SSL Client Context (Rule: Accept incoming HTTPS connections) and enables the SSL Scanner (Rule: Content inspection)

SSL Client Context without CA setting:


Date: 2011-07-13

2011 of 22


Important here is that the server certificate should be issued for “*.<DOMAIN>”, in our example “*.example.com”

9 Rule set “Authentication Server”

This rule set will be executed during a SSL-Connection on port 444. This is a redirection from the internal SSL-Connection when no valid cookie has been sent.

“Authentication Server” contains the rule sets:

Authenticate Certificate

Create and send Certificate

Create and send Cookie

9.1 Authenticate Certificate

This rule set asks the mobile device for a client certificate. When the device doesn‟t send a certificate or the certificate is invalid, the authentication fails and the next rule ‘Create and send Certificate’ is executed. This rule should only be used if no other


Date: 2011-07-13

2011 of 22


possibility exists to create a certificate. It can be enhanced to generate a certificate only if e.g. the device is inside the internal company network.

If you want to use your own created certificate at this place you will need to enter the root CA.

Important – the Authentication method will have to be set to “SSL Client Certificate Authentication”. Setting “Check extended key usage” requires a client certificate that specifies this flag; client certificates created by MWG7 include it whereas client certificates created by “Tiny CA2” by default do not include the extended key usage flag.


Date: 2011-07-13

2011 of 22


9.2 Create and send Certificate

This rule set should be used only as option if no other way exists to issue a client certificate.

This rule is executed if the certificate validation fails or the certificate is in the list ‘Disabled Client Certificates’. The mobile device user has to authenticate itself and if successfully authenticated a certificate will be created and a download page is send to the device. To download the certificate the user must click the download link. A special request is send to the proxy to send the certificate. This special request isn‟t handled by the rule engine. The serial of the certificate is written to the mwg-core__MobileDeviceCertificates.debug.log. To disable a certificate this serial must be inserted into the list „Disabled Client Certificates’. The CA of the „Mobile Device Certification‟ setting must be the same as the CA used in the certificate authentication.

The parameter “Password” in the screenshot is the password used for the client certificate generation. It is valid for all client certificates.

The certificate has been downloaded and installed, the device‟s browser has been restarted, now the request is authenticated and it reaches the next rule set.

9.3 Create and set a Cookie

This rule set will be executed if the authentication of the sent client certificate was successfully. It creates and sets a cookie and redirects to the internal SSL-Connection.


Date: 2011-07-13

2011 of 22


The cookie is calculated based on the property “SecureToken.CreateToken(Client.IP)”. This property requires a secret with which a series of hashes is calculated (based on AES128, SHA1 and base64).

It is also possible to add a timestamp as to include this information into the cookie.

10 Rule set “Reverse Proxy Feature”

This rule set does the following

Redirects internal SSL-Connections without a valid cookie to the authentication server.

Sets the URL of the cookie authenticated internal SSL-Connection to the original URL requested by the browser, if the host is in the list of allowed hosts (Rewrite Hosts Target).


Date: 2011-07-13

2011 of 22


10.1 Request Redirections

The first ruleset contains one example which changes the URL from http://www.example.com to https://www.example.com. More rules for exceptions can of course be added.

In the second step, all non internal SSL Connections are then changed to an internal SSL-Connection.

10.2 Authentication

This rule set does the following:

Extracts the cookie.

Checks the cookie if it matches a valid value (with the help of “SecureToken.GetString).

If the cookie is not valid, redirects to the authentication server listening on port 444.

http://www.example.com/

https://www.example.com/


Date: 2011-07-13

2011 of 22


One important thing is to change the authentication server to MWGs domain in “Redirect to Authentication Server” setting:

If this is not changed, the authentication server process will not work.

10.3 Secure Reverse Proxy

This rule resets the URL of a valid and authenticated reverse proxy request (internal SSL-Connection) to the original URL sent by the devices‟ browser, if the host is allowed to connect to.


Date: 2011-07-13

2011 of 22


“Map Hosts RewriteHostsSource to RewriteHostsTarget” maps special source hosts to destination hosts.

The Rule that finally converts the https urls (like e.g. https://server1-de-r-http.example.com) back to “normal” urls that are sent “out” to the internal network (e.g. http://server1.de) is Rewrite URL

Important: if you disable the rule Block All Requests Not in List Rewrite Hosts Target then all URLs are accepted!

11 What to configure on an iDevice if the client certificate is created by MWGs ruleset

If the mobile device user does not possess any client certificate, the Ruleset “Create and Send certificate” can be used to assist in creating a client certificate.

What happens if this ruleset is enabled and the Safari browser does not send a client certificate:

- The user will have to authenticate himself (by default based on basic userdatabase authentication).

https://server1-de-r-http.example.com/



Date: 2011-07-13

2011 of 22


- After authentication has succeeded, MWG will redirect to the download page of the certificate:


Date: 2011-07-13

2011 of 22


- Enter the password specified in rule Create a Certificate and Send the Download Page


Date: 2011-07-13

2011 of 22


- The client certificate should be installed now.


Date: 2011-07-13

2011 of 22


- Now the (Safari) browser must be restarted, all future Safari sessions are authenticated.

12 Tips

Q: Why is http://server1.de converted to https://server1-de-r-http.example.com/?

A: the http url is redirected to a https url that MWG7 can parse correctly. Due to the fact

that server certificates like *.example.com are only valid to one level (e.g. server1.example.com) would be two levels below!), we had to figure out a way how to change the URL without changing the validity of a *.domain certificate. That‟s why we opted for the syntax





Date: 2011-07-13

2011 of 22


where a dot gets converted to a hyphen and a hyphen gets converted to two hyphens, and a unique string is added.

When MWG7 goes “out” to the area where our internal web servers are, the original URL will be used. In this case MWG7 just inverts the conversion.

Q: Somehow the routing through my MWG is not working OK, what could be the reason for this?

A: make sure that MWG listens on port 80 or that iptables rules are set to NAT requests

with destination port 80 to the proxy port. And do not forget to set ports 443 and 444 in Configuration > Proxies

This is an example of the configuration on port 80:

Q: Why do some linked URLs on my internal websites not work?

A: as mentioned in chapter 6, it is possible that the server uses direct links or redirects to absolute URLs outside the internal network or that the site intends to download some content directly from these sources. Those links will not work with the ruleset provided. For this case it would be necessary to add a ruleset that would parse the response directly and trigger a reverse mapping, something that is not yet implemented.

whitepaper: mcafee web gateway mobile security

Documents