What to do when users get browser and smartphone security warnings when connecting to your network

ANTlabs gateways have a unique feature that can redirect HTTPS web requests to the captive portal or landing page. This feature was very useful earlier in comparison to other competitors that can only redirect HTTP web requests, thus enhancing customer experience.

Recently, browsers like Google Chrome and Mozilla Firefox started to warn their users of a potential security risk when they detect that the requested domain name and the certificate offered to it doesn’t match. This warning page allows users to accept the risk and continue, after which the users will be redirected to the captive portal or landing page. However, with even stricter control by the browsers and some of the latest smartphones, this warning message has deterred users to login to the WiFi network.

This advisory explains the different issues related to the HTTPS and captive portal or landing page redirection and suggests several options and recommendations to overcome them. Note: ‘ANTlabs gateway’ could mean any series of SSG, SG, and IG gateway models. This advisory also assumes that the captive portal’s domain name uses the default ezxcess.antlabs.com domain name. For a custom domain name with a valid certificate matching the domain name, the warning messages or certificate errors may or may not appear depending upon the browsers and OS versions.

Current User Experience on Different Devices and Browsers

LAPTOP AND NOTEBOOK WITH WINDOWS 10 OPERATING SYSTEM

The following flow describes the user experience when connecting to the WiFi network using his Windows 10 OS on a Laptop or Notebook.

• User connects to the Open WiFi SSID
• The Laptop or Notebook obtains IP address
• Windows 10 WiFi Manager will detect that the device does not have internet access and opens the default browser with a HTTP website and check if it can reach this website.
• Since the laptop does not have internet access yet, ANTlabs gateway will then redirect the HTTP page to the HTTPS-based captive portal or landing page
• Depending upon the browser, the user will see different messages or warnings, as shown on the images:

Microsoft Edge

Google Chrome

Mozilla Firefox

Internet Explorer

Smartphones with Apple iOS or Android OS

The following flow describes the user experience when connecting to the WiFi network using his Smartphones running on either latest Apple iOS or Android OS

1. 1. Auto–popup of device pseudo-browser
      • User connects to the Open WiFi SSID
      • The Smartphone obtains IP address
      • Apple’s Captive Network Assistant (CNA) and Android’s Captive portal login shall detect that the smartphone does not have internet access and auto-popups the HTTPS captive portal or landing page
      • The user will see warning messages as shown on the images:
   2. Login using devices’ mobile browser and entering HTTPS website manually
      • User connects to the Open WiFi SSID
      • The Smartphone obtains IP address
      • The pseudo browser is disabled
      • User opens the native browser and types in a HTTPS web request
      • The browser detects that the requested HTTPS domain name and the offered Certificate domain names mismatch and shows a warning page
      • User clicks on continue to the website and sees the captive portal or landing page
   3. Login using devices’ mobile browser and entering HTTP with HSTS enabled manually
      • User connects to the Open WiFi SSID
      • The Smartphone obtains IP address
      • The pseudo browser is disabled
      • User opens the native browser and types in a HTTP web request
      • The HTTP Web server has HSTS enabled and hence redirects to its HTTPS domain
      • The browser detects that the requested HTTPS domain name and the offered Certificate domain names mismatch and shows a warning page
      • User clicks on continue to the website and sees the captive portal or landing page
      • Some stricter websites such as google does not allow the option to proceed, if used on a Google Chrome web browser.

2. Analysis

   HTTPS is designed to protect the users from man-in-the-middle and eavesdropping attacks. Web browsers have pre-installed certificate authorities in their software to trust HTTPS websites. Latest versions of Chrome, Firefox and Smartphone pseudo browsers changed the way to warn their users when they detect any abnormality in the way a HTTPS website should naturally work.

   The following are the different types of issues that the browsers shall respond with for HTTPS captive portal or landing page:

   WEBSITE DOMAIN NAME AND CERTIFICATE HOSTNAME MISMATCH

   Whenever a web browser requests for a HTTPS website, the website will provide a valid certificate with the hostname of the certificate matching the exact domain name or sub-domains in case of wildcard certificates.

   Before a client is authenticated or logged in to the WiFi network, ANTlabs gateway redirects the HTTPS request and provides it with its own certificate. When the browser detects that the requested HTTPS domain name and the received certificate hostname mismatches, it shows a warning page.

   1. E.g. 1: The user is browsing https://mail.mycompany.com . ANTlabs gateway redirects the user to https://ezxcess.antlabs.com/… If the ANTlabs gateway provides the browser with a certificate with hostname for ezxcess.antlabs.com, but the requested website was mail.mycompany.com, due to this mismatch, the browser displays security warning message and with an option to continue or cancel the request.
   2. E.g. 2:  the browser redirects to the landing page with domain name ezxcess.antlabs.com but the certificate hostname is login.required.open.http.page

UNTRUSTED CERTIFICATE WARNING

The browser complains that a certificate is “Untrusted” for two reasons, as below:

1. 1. 1. If the certificate is a self-signed certificate. i.e. it is not signed by a global trusted CA
      2. If the device cannot verify the root CA or the root CA is not in the device trusted list

HTTP STRICT TRANSPORT SECURITY (HSTS)

HTTP Strick Transport Security (HSTS) is a web security policy mechanism which allows web servers to declare that web browsers should only interact with it using a secure HTTPS mechanism.

When a web application issues HSTS Policy to the web browser, those web browsers that conform behave as follows:

1. 1. 1. Automatically turn any HTTP links referencing the web application into secure links. (For instance, http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.)
      2. If the security of the connection cannot be ensured (e.g. the server’s TLS certificate is not trusted), show an error message and do not allow the user to access the web application.

Solutions for Mitigating Captive Portal HTTPS Redirect Issue

To overcome the issues in modern web browsers, the following solutions are proposed:

USE GLOBAL TRUSTED ROOT CA SIGNED CERTIFICATE

It is advisable to purchase and use a certificate that is signed by a Global Trusted Root CA. This Root CA should be as part of the trusted list for major devices such as Apple, Android, Windows and operating systems. If there are intermediate CA certificates, those should also be added in the ANTlabs gateway.

WHITELIST HTTPS DOMAINS OF HTTP DOMAINS

It is recommended to whitelist or wall-garden the HTTP domains in the HTTPS domains as well. This shall ensure that those HTTP Web servers that are configured for HSTS will still be able to be accessed before login, and thereby will not show any warning messages.

STOP HTTPS REDIRECTION TO CAPTIVE PORTAL

In addition to the above prevention methods, the ANTlabs Gateway will also be configured to drop all HTTPS requests before user login. This will solve the security warning messages that the users are currently seeing in their browsers. Instead, users will see a default browser page that states that the connection to the website cannot be established. With the majority of the latest browsers automatically verify and redirect based on HTTP websites and pop-up the pseudo-browsers, this method shall enhance the user experience.

NOTE: Older operating systems that may use HTTPS requests to auto-popup pseudo browsers shall show a network connection error message in the pop-up browser

Industry References in Solving this Browser Behavior

Most of the CSPs that provide Public WiFi is moving towards seamless authentication mechanisms that do not use the captive portal or landing pages. Various EAP methods such as EAP-SIM/AKA, EAP-PEAP, EAP-TTLS are being used to authenticate the users seamlessly. In some customers, the EAP methods are combined with mobile applications, thereby making it easier for users to onboard and authenticate. Apart from EAP methods, some customers are also implementing Mobile applications with WISPr 1.2 based authentication method. If for marketing purposes and customer engagement the captive portal or landing page is necessary, ANTlabs gateway’s unique feature allows to pop-up the page after the user has been authenticated using any of the above mechanisms.

Related Posts