Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco ScanCenter Administrator Guide, Release 5.2

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco ScanCenter Administrator Guide, Release 5.2

Chapter Title

Cloud Web Security Mobile Browser

Results

Updated:
February 16, 2021

Chapter: Cloud Web Security Mobile Browser

Cloud Web Security Mobile Browser

Overview

The Cisco Cloud Web Security (CWS) Mobile Browser solution allows you to set up and deploy a secure web browser onto your mobile devices and protect its web usage with Cisco CWS. HTTP/HTTPS traffic is redirected to Cisco CWS for inspection and controlled by the policy you configure in Cisco ScanCenter.

Table 1. Operating Systems and Mobile Devices Currently Supported

Operating System

Mobile Devices

Apple iOS 8.4 and higher

iPhone 5, 5s, 6, 6 Plus, 6s, 6s Plus

iPad 3, 4, Air, Air 2, all Mini models

iPad Pro is not supported

Android 4.4 and higher

Android 6.0 is not supported

Any mobile smartphone or tablet should be supported. Testing has been performed on devices including Samsung Galaxy S6, LG Nexus 5, LG Nexus 4, and ASUS Nexus 7. Devices running Android variants, such as Kindle, are not supported.


Note

We do not provide technical support for third-party products such as the mobile device. For any issues with the mobile device, consult the vendor-specific support team.


Note

Currently, the Shift_JIS character encoding set is not supported.

The Cisco CWS Mobile Browser (referred to here as mobile browser) has two separate user interfaces: one for mobile smartphones and one for tablets. These user interfaces have been designed to make efficient use of screen space on both form factors. Also, the iOS and Android user interfaces differ, reflecting the differing design languages to match expectations of how to interact with the app.

The following main functionalities are supported in the mobile browser:

  • Multiwindow (smartphone) or multitab (tablet) browsing

  • Web search using the address bar, configurable search engine (defaults to Google)

  • Browsing history and bookmarks

  • Sharing content through email, SMS, and various other applications

  • Ability to clear cookies, cache, and browsing history

    Note

    Depending on your policy configured in Cisco ScanCenter, the browsing history may still be recorded on the Cisco CWS server.

  • Ability to email diagnostic logs to an email address

    Note

    Diagnostic logs should be included in any bug reports.

  • Ability to brand the new window or tab screen with your company name and logo

  • Your company name and logo would be clickable with your corporate URL

Provisioning

The mobile browser provisioning process consists of delivering the application to install on the mobile device and distributing the configuration file to configure the application.

Deliver the Application

This section describes how to deliver the mobile browser app across your inventory of mobile devices running either iOS or Android.

Application on iOS

The two options to deliver the mobile browser app on iOS are:

  • Automated process using mobile device management software.

  • Manual process using Apple's App Store.

Deliver Application Using Management Software

One way to deliver the mobile browser on iOS is using Mobile Device Management (MDM) or Enterprise Mobility Management (EMM) software. This method allows you to silently and efficiently deliver the application to your mobile devices running iOS. To use this method, your MDM or EMM software provider must support application delivery using Apple's App Store and Managed App Configuration.


Note

Cisco does not provide support for third-party MDM or EMM software. Contact the vendor of your third-party management software for information on how to use their product for app deployment.

Using your third-party MDM or EMM software:

Procedure
Step 1

Create a policy to deploy an App Store application.

Step 2

Search for "CWS Browser" in the App Store, and select the application.

Step 3

Configure the policy to deploy the mobile browser app.

Step 4

Deploy the policy. The app gets pushed to your target devices and becomes visible on the device's Home Screen.

What to do next

Cisco may issue updated builds of the mobile browser that address issues or add functionality. Whether you automatically receive updates depends on your MDM or EMM policy.

Deliver Application Using App Store

Another way to deliver the mobile browser on iOS is directly installing the application using Apple's App Store. Instruct your users to open the App Store to find, download, and install the "CWS Browser" app. To avoid accidentally installing an incorrect application, email your users with an up-to-date and direct link to the App Store listing for the mobile browser.


Note

Cisco may issue updated builds of the mobile browser that address issues or add functionality. Whether you automatically receive updates depends on whether you have configured your inventory of iOS devices to receive automatic updates from the App Store.

Application on Android

The mobile browser app for Android is a binary in .apk format. Android application package (APK) is the package file format used by the Android operating system for distribution and installation of application software. The mobile browser app is hosted on the Google Play store. Instruct your users to open the Google Play store to find, download, and install the "CWS Browser" app. To avoid accidentally installing an incorrect application, email your users an up-to-date and direct link to the Google Play store listing for the mobile browser.

Another way to deliver the mobile browser from the Google Play store is using MDM or EMM software. Currently, Cisco does not support this method or provide support for third-party MDM or EMM software. Contact the vendor of your third-party management software to determine if this method is possible.


Note

Cisco may publish updated builds of the mobile browser to the Google Play store that address issues or add functionality. If you have configured your inventory of Android devices to automatically update from the Google Play store, these updated builds may be installed automatically.

Distributing the Configuration File

The configuration file contains information that determines the behavior and functionality of the mobile browser app. Use a file manager, not the download manager, to open the configuration file as type other. On both iOS and Android, the configuration file must have the .cwsconfig extension. Both iOS and Android configuration files use the same property=value format. You can populate the properties in the file with values to suit your deployment needs. Distribute the configuration file onto your mobile devices using email, web distribution, or management software on iOS.

Configuration File Properties

Property Expected Value Description
cws_aup_enabled true or false

Default is false.

Whether AUP functionality is enabled; see Acceptable Usage Policy.
cws_auth_licence_key String containing your license key. (Required) Your Cisco CWS license key (company, group, or user) is required to authenticate the device.
cws_company_image Base 64 representation of an image.

Default is Cisco branded.

Your company image or logo; see Branding.
cws_company_text String containing your company name.

Default is Cisco branded.

Your company name; see Branding.
cws_company_url String containing your company web URL.

For example, http://www.cisco.com.

Default is empty.

Your company URL; see Branding.
cws_easyid_saml_enabled true or false

Default is false.

Whether EasyID or SAML is being used. Hints to the mobile browser to allow third-party cookies.
cws_exception_poll_interval Number in seconds.

Default is 3600.

Time in seconds specifying how often the allowed list configuration is retrieved.
cws_fail_open_enabled true or false

Default is false for fail closed.

Whether the browser should fail open on a proxy error; see Fail Open or Fail Closed.
cws_trusted_network_beacons Comma-separated array containing:

hostname:port|SHA256 certificate hash

Default is empty.

Array of beacon servers for Trusted Network Detection functionality; see Trusted Network Detection.
cws_trusted_network_poll_interval Number in seconds.

Default is 300.

Time in seconds specifying how often the beacon server is polled to detect the presence of a trusted network.
mdm_vendor String containing the MDM name.

Default is empty.

(iOS only) Name of the MDM software used for provisioning.
mdm_version String containing the MDM version..

Default is empty.

(iOS only) Version of the MDM software used for provisioning.

Configuration File Template

The following configuration file template may be used to create your company-specific configuration file. For information on each property and its expected value, see Configuration File Properties.


Note

The cws_auth_licence_key property value is required. All other properties are optional. If you wish to omit a property and inherit its default value, completely remove the property from the configuration file, do not leave it blank. For example, if you do not want to configure a company-specific logo, remove the entire cws_company_image= line.

Configuration File Template for iOS: 

cws_aup_enabled=false
cws_auth_licence_key=
cws_company_image=
cws_company_text=
cws_company_url=
cws_easyid_saml_enabled=false
cws_exception_poll_interval=3600
cws_fail_open_enabled=false
cws_trusted_network_beacons=
cws_trusted_network_poll_interval=300
mdm_vendor=
mdm_version=

Note

The mdm_vendor and mdm_version properties are for iOS only and are reserved for future use. Ensure that you remove these lines when creating a configuration file for Android.

Configuration File Template for Android: 

cws_aup_enabled=false
cws_auth_licence_key=
cws_company_image=
cws_company_text=
cws_company_url=
cws_easyid_saml_enabled=false
cws_exception_poll_interval=3600
cws_fail_open_enabled=
cws_trusted_network_beacons=
cws_trusted_network_poll_interval=300

Configuration on iOS

There are three options to distribute the configuration file onto mobile devices running iOS.

Deliver Configuration Using Email

Distribute the configuration file using email.

Before you begin

Once you have created your configuration file as a property list, ensure that it has the .cwsconfig file extension. For example, testfile.cwsconfig

Ensure that the user has installed the mobile browser from the App Store before attempting to install the configuration.

Procedure
Step 1

Attach the .cwsconfig file to an email.

Step 2

Send the email to an email address the user has configured in the email client on their mobile device, which may or may not be their corporate address.

Step 3

After installing the CWS Browser from the App Store, open the email.

Step 4

Tap and hold on the attachment. After a few seconds, the share sheet appears.

Step 5

Select Copy to CWS Browser. The mobile browser opens and configures itself based on the configuration file.

Deliver Configuration Using Intranet Web Server

Distribute the configuration file by hosting the configuration file on a web server within your corporate Intranet.

Before you begin

Once you have created your configuration file as a property list, ensure that it has the .cwsconfig file extension. For example, testfile.cwsconfig

Ensure that the user has installed the mobile browser before attempting to install the configuration.

Procedure
Step 1

Add to your web server configuration a MIME type of application/cwsconfig for the .cwsconfig file name extension.

Step 2

Upload the .cwsconfig file to a web server on your corporate Intranet.

Step 3

Distribute the web URL for the .cwsconfig file to your users by a means such as email.

Step 4

After installing the mobile browser app, use Safari on the mobile device to browse to the web URL from Step 3.

Step 5

Tap the screen, select Open In, and choose Copy to CWS Browser. The mobile browser opens and configures itself based on the configuration file.

Deliver Configuration Using Management Software

Distribute the configuration file using MDM or EMM software. This method allows you to silently and efficiently deliver the configuration file to your mobile devices running iOS. To use this method, your MDM or EMM software provider must support delivery using Apple's Managed App Configuration. This method is also secure: once the app is configured, it rejects any attempt to reconfigure it, which prevents accidental or malicious reconfiguration.


Note

Not all MDM and EMM solutions support Apple's Managed App Configuration. Contact the vendor of your third-party management software to find out if this feature is supported and how to configure it. Cisco does not provide support for third-party MDM or EMM software.

Procedure
Step 1

When configuring the Managed App Configuration, you are prompted to specify the Bundle Identifier. Enter com.cisco.cwsbrowser

Step 2

Specify the configuration properties as property=value pairs.

Step 3

Once the Managed App Configuration settings are pushed to the mobile devices, the mobile browser automatically picks up the configuration with no additional steps required.

Configuration on Android

There are two options to distribute the configuration file onto mobile devices running Android.


Note

There is a known issue on Android regarding installation of the configuration file. The app will not accept a new or updated configuration file if the app is running in the background. Therefore, after downloading the app, swipe to close the app before installing the configuration file.

Deliver Configuration Using Email

Distribute the configuration file using email.

Before you begin

Once you have created your configuration file as a property list, ensure that it has the .cwsconfig file extension. For example, testfile.cwsconfig

Ensure that the user has installed the mobile browser from the Google Play store before attempting to install the configuration.

Procedure
Step 1

Attach the .cwsconfig file to an email.

Step 2

Send the email to an email address the user has configured in the email client on their mobile device, which may or may not be their corporate address.

Step 3

After installing the CWS Browser from the Google Play store, open the email.

Step 4

Tap the attachment. You are prompted with a list of apps with which to open the configuration file.

Step 5

Select CWS Browser. The mobile browser opens and configures itself based on the configuration file.

Deliver Configuration Using Intranet Web Server

Distribute the configuration file by hosting the configuration file on a web server within your corporate Intranet.

Before you begin

Once you have created your configuration file as a property list, ensure that it has the .cwsconfig file extension. For example, testfile.cwsconfig

Ensure that the user has installed the mobile browser before attempting to install the configuration.

The web server must not require authentication; it must not use techniques such as HTTP basic, digest auth, or NTLM.

Procedure
Step 1

Add to your web server configuration a MIME type of application/cwsconfig for the .cwsconfig file name extension.

Step 2

Upload the .cwsconfig file to a web server on your corporate Intranet.

Step 3

Distribute the web URL for the .cwsconfig file to your users by a means such as email.

Step 4

After installing the mobile browser app, use Chrome on the mobile device to browse to the web URL from Step 3.

Step 5

Chrome automatically offers to open the URL in the mobile browser, at which point the mobile browser loads the file and applies the configuration.

Policy

Authentication

When using the mobile browser, user authentication is supported in three ways:

  • License Key. The simplest form of authentication is license key authentication in which you create a license key representing your whole company (company key), a group of users (group key) or a specific user (user key). Each of these levels of key granularities is supported by the mobile browser.

  • In conjunction with the license key, you may establish user granularity by using SAML or EasyID. SAML works by authenticating the user on the mobile browser with your company's identity provider (IdP).

  • EasyID works by authenticating them directly against your LDAP server. The user is prompted to authenticate upon hitting an authenticate policy, which is defined in Cisco ScanCenter. For more information about SAML, EasyID, and authenticate rules, see Authentication.

Third-party cookies must be enabled in the mobile browser for EasyID or SAML to function correctly. For the mobile browser to be compatible with EasyID or SAML authentication, the cws_easyid_saml_enabled property must be set to true in the configuration file. This setting enforces that third-party cookies must be enabled in the mobile browser.


Note

Due to limitations in the Android app, if you wish to use SAML authentication with the Android app, your IdP must be exposed to the public Internet. Also, the IdP must not be allow listed in the Cloud Bypass list. In other words, requests to the IdP must go through the CWS proxy. Ensure that any domains associated with your IdP are exempted from any authentication policy. Also, you may wish to exempt your IdP from any HTTPS Inspection policy.

Acceptable Usage Policy

AUP is a feature that allows you to ensure that your employees read your company AUP either every day or every week. This feature is also part of the CWS Connector, so you may already have it configured. For more information on how to configure the AUP, see Acceptable Usage Policy.


Note

Set the cws_aup_enabled property in the mobile browser configuration file to true.

Web Filtering

Web filtering policy is configured using Cisco ScanCenter, the portal to Cisco CWS.

  • Block access to certain websites.

  • Warn a user about browsing to certain websites.

  • Anonymize user information from reporting on certain websites.

If you are using a group key to authenticate the mobile browser as recommended, you may want to create special policies to apply to this group. For information on how to create policies in Cisco ScanCenter, see Policy.

Cloud Bypass Allow Listing

The mobile browser supports the Cloud Bypass functionality used by Cisco ISR G2 and Cisco 4000 Series ISR routers with Cisco CWS. Cloud Bypass allows you to create an allowed list specifying a set of domains you do not want scanned by Cisco CWS. If a request to one of these web pages is made through the mobile browser, it is sent directly to the Internet rather than through the Cisco CWS proxy.

One use case for this functionality is internal domains such as Intranet sites that are not accessible through Cisco CWS infrastructure. Another use case is requests to sensitive domains where you may not wish to proxy requests for legal or policy reasons.

The allowed list itself is hosted in the cloud and configured through Cisco ScanCenter. For more information on how to create an allowed list, see Cloud Bypass.

The allowed list is retrieved from the cloud by the mobile browser every configurable number of seconds. The cws_exception_poll_interval property in the mobile browser configuration file has a default of every 3600 seconds. When the app restarts, it also retrieves the allowed list. If there is an error when retrieving the allowed list, the previous version of the allowed list is used.


Note

A limitation exists on the Android version of the mobile browser where resource requests inherit the allowed list state of the parent page. For example, you load a page such as Cisco.com/page1.html and this page contains resources such as opendns.com/image.jpg. If Cisco.com is allow listed, the request to opendns.com/image.jpg is also allow listed, and vice versa.

HTTPS Inspection

The mobile browser supports the Cisco CWS HTTPS Inspection functionality. This functionality allows Cisco CWS to decrypt HTTPS traffic in order to apply policy, filtering, and scanning. By default, this functionality is switched off in Cisco ScanCenter. If you want to use this functionality, enable it in Cisco ScanCenter, create HTTPS Inspection policies, and generate a company-specific certificate. For more information, see Secure Traffic Inspection.

Once this functionality is enabled in Cisco ScanCenter, install the company-specific certificate onto the mobile device. The mobile browser reads this certificate from the device trust store. If you do not install the certificate, you may be presented with certificate warnings when browsing to inspected HTTPS websites.

Use your company's MDM or EMM to install the certificate. Alternatively, send the certificate as an email attachment, or host the certificate on a web server for the user to navigate to and download. The mobile browser app itself does not handle certificate installation.

Reporting

As with any other Connector, web traffic from the mobile browser is logged in the Cisco CWS reporting service. For more information on reporting in Cisco ScanCenter, see Getting Started with Reports.

Specific telemetry reported by the mobile browser include:

  • Connector OS name. For example, iPhone OS.

  • Connector OS version. For example, 9.0.2.

  • Connector version.

    • For the mobile browser, SMBx.x.x where x.x.x is the version number.

    • For example, SMB1.0.1.

  • Connector GUID.

    • Android only.

    • For example, 18502ABC.

    • Corresponds to the device serial number.

    • Field is anonymized if you browse to a site under an anonymization rule.

Branding

In the mobile browser, you can apply your corporate branding to the new window page. Customize this page by setting the following properties in the mobile browser configuration file:

  • Corporate logo.

    • Set cws_company_image to a base 64 encoded string representing your image.

    • Get the base 64 encoding of your logo by running the following command in the terminal or command prompt (Windows users must install OpenSSL): 
      $ openssl base64 -in corporateLogo.jpg

  • Corporate text. Set cws_company_text to your company name.

  • Corporate URL. Set cws_company_url to your corporate home page.

Captive Portal Detection

The Captive Portal Detection functionality in the mobile browser allows you to browse the Internet even when you are connected to a captive portal network. A captive portal network is a Wi-Fi network that requires you to log in to a web page before you are permitted access to the Internet. These networks are commonly found in airports, hotels, and coffee shops.

On iOS, the operating system detects and handles captive portal networks. When you connect to a captive portal network, the operating system presents you with the sign-in page, and enforces you to either log in or cancel your connection request. Therefore, the mobile browser on iOS does not need any special functionality to be compatible with captive portal networks. However, in cases where the captive portal network attempts to tamper with or bypass the iOS captive portal network detection, such networks may be incompatible with the mobile browser.

On Android, the operating system partially handles captive portal networks: it can detect when it is connected to a captive portal network but will not enforce the user to sign in or abandon their connection attempt. Therefore, the mobile browser on Android has detection and handling functionality built in. When the mobile browser on Android detects a captive portal network, it stops forwarding traffic to Cisco CWS. You then sign into the captive portal network, as you would normally on another web browser such as Chrome. Once you have signed in, the mobile browser detects that wider internet access has been restored, and begins redirecting traffic to Cisco CWS.


Note

Some captive portal networks block proxies. TCP port 8080 is used by the mobile browser. Such captive portal networks are incompatible with the mobile browser unless the fail open functionality is enabled. For more information, see Fail Open or Fail Closed.

Trusted Network Detection

The Trusted Network Detection (TND) functionality allows you to configure the mobile browser to know when it is on what you define as a trusted network. When the mobile browser is being used on a trusted network, it will not redirect traffic to Cisco CWS and instead, sends traffic directly to the Internet.

One use case for this functionality is defining your internal network as a trusted network. This allows the mobile browser to access internal resources on your Intranet when on your corporate Wi-Fi or VPN. Another use case is if you have another on-premises Cisco CWS Connector or Cisco security product that you would prefer the mobile browser traffic to be routed through.

TND is configured by specifying a set of beacon servers and ports that the mobile browser can attempt a TLS handshake with. The beacon servers do not require any specialized software. The mobile browser must be given a SHA256 checksum or fingerprint of the certificate for the beacon server. The mobile browser attempts a TLS handshake with this server and compares the checksum with its expected checksum. If there is a match, the mobile browser then knows that it is on a trusted network and stops sending its traffic to Cisco CWS. If there are multiple trusted network beacon servers defined, they are polled in sequential order until one matches. If none of them match, the mobile browser then knows that it is on an untrusted network and will proxy its traffic to Cisco CWS.

TND polling is triggered upon a network change: for example change of Wi-Fi network, Wi-Fi to cellular, cellular to Wi-Fi, or VPN connection gets established or disconnected. Also, TND polling occurs in every configurable number of seconds. Configure the number of seconds by setting the cws_trusted_network_poll_interval property in the mobile browser configuration file. The default value is 300 seconds.

Beacon Server Configuration

TND beacon servers are specified in the configuration file using the cws_trusted_network_beacons property.

The property is a string with the following format: 

BeaconServer_1:BeaconPort_1|SHA256HASH_1,BeaconServer_2:BeaconPort_2|SHA256HASH_2,
			 … , BeaconServer_N:BeaconPort_N|SHA256HASH_N

For example: 

web.intranet.com:443|900fc753b7fec06eb30d092620244e0c83d78d6c0324612de068274a86077476,
ssh.intranet.com:22|343d7b76e59cbf9cb9d5b2d4917d7ab89b809ccd95e824fdeee5837dfb3471c6

One way to obtain the SHA256 hash of your server certificate is to use the following command in a Unix terminal: 

$ openssl s_client -connect web.intranet.com:443 2>/dev/null 
  </dev/null | openssl x509 -noout -fingerprint -sha256


SHA256 Fingerprint=
41:10:A0:6E:00:E1:4A:B4:C5:38:B0:DE:0C:98:68:40:9C:09:E1:04:D6:FD:BD:80:94:74:53:3D:D1:CD:23:AC

Be sure to remove the colons to get: 

4110A06E00E14AB4C538B0DE0C9868409C09E104D6FDBD809474533DD1CD23AC

Fail Open or Fail Closed

The mobile browser allows you to specify its behavior in case it's unable to connect to Cisco CWS. Choose fail open to allow all mobile browser web traffic to go directly to the Internet, or choose fail closed to block all mobile browser web traffic until connectivity is restored.

Examples of events that could trigger a fail open or fail closed scenario include:

  • Cisco CWS infrastructure error or outage.

  • DNS failure on the network.

  • TCP port 8080 or communication with Cisco CWS blocked by a firewall.

  • Packet loss between the network and Cisco CWS.

  • Other network connectivity issues.

By default, the mobile browser fails closed. Fail open can be enabled by changing the cws_fail_open_enabled property in the mobile browser configuration file to true.


Note

A captive portal network is a special case handled differently. For information, see Captive Portal Detection.

If fail open is enabled, the mobile browser temporarily disables redirection of traffic to Cisco CWS and checks whether Cisco CWS is reachable again after 60 seconds. If Cisco CWS is reachable, the mobile browser redirects its traffic to Cisco CWS. If not, another attempt is made after two minutes, three minutes, four minutes, and every eight minutes, if needed. If you quit the app entirely, dismissing it from the multitasking menu on the OS, and reopen it, this also triggers a fail open check.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

Related Cisco Community Discussions

About Us
Contact Us
Work with Us