Blocked Nodes are not redirected to CWP page

With all systems utilizing Captive Portal technology, there are some inherent issues that are present due to the underlying protocols and functionality associated with a Captive Portal environment. This document will discuss the most common issues and available workarounds.

Symptom 1

Certificate Warnings

The first issue is certificate warning messages being displayed to the end user upon a Captive Portal redirect. Language may vary but typically a message similar to "Your connection is not private" may be displayed to the end user as a warning. This issue is well known in Captive Portal environments and is the expected behavior.

Cause 1

The cause of this issue is the technology that is used during a Captive Portal redirect for an HTTPS website.

The diagram below depicts the flow when a host accesses an HTTPS website when no Captive Portal is present:

HTTPS communication requires intercommunication between the Web Server and the PC for encrypted communication before creating a cryptographic session.

1. Client hello: PC notifies Web Server of HTTPS communication request
2. Server Hello, Certificate: The server passes the certificate to the client, the client determines that the certificate is a trusted certificate
3. Client Key Exchange: The client sends the pre-master-secret key to the Web Server, Symmetric key sharing
4. Finish: After the end of the negotiation process, communication is exchanged by a symmetric key exchange

After that, encrypted communication is established between the PC and Web Server using the encrypted channel.

For comparison, the diagram below depicts the flow when a host accesses an HTTPS website when a Captive Portal is present:

The important point here is that the server certificate is transmitted to the CA certificate (FAKE Certificate) of the Captive Portal system so that the encrypted communication is not connected to the original target Web Server, but instead the session is established with the Captive Portal Web Server.

Resolution 1

For the reasons listed above, end users must acknowledge the certificate warning, typically by clicking “Continue” before being redirected to the Captive Portal page.

Most modern operating systems now have built-in Captive Portal detection capability. Windows 10 Captive Portal Detection, Apple Captive Network Assistant and Android Connectivity Manager are all examples of this feature. These features function by sending out HTTP requests to various URLs pre-defined at the OS level to determine if the device is behind a Captive Portal. If no response is received, it is assumed the device is behind a Captive Portal. At that point, the operating system will automatically invoke an HTTP request using the default browser. Because the request is HTTP and not HTTPS, Captive Portal redirection occurs without any issues.

Captive Portal detection in general is not a perfect science, however, ensuring all packets are blocked the moment a device connects results in a higher probability of Captive Portal detection functioning properly, thereby bypassing the issue of certificate warnings. Genian ZTNA is constantly improving features and a new feature is being implemented which should ensure that the majority of the time endpoint device Captive Portal detection is triggered. This document will be updated with additional information when the feature is available.

Symptom 2

HSTS Websites – Browser Does Not Allow Redirect

What is HSTS? At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks (which is what a Captive Portal redirection is) and cookie hijacking.

Cause 2

Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security). Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL “Strict-Transport-Security: max-age=31536000” (one year). The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and, if the certificate does not match, the browser will not allow the connection to site to be established. For users behind a Captive Portal, this is where they reach a dead end because accepting a certificate warning will not allow them to proceed.

Resolution 2

For users visiting an HSTS website behind a Captive Portal the only option is to browse to a non-HSTS website. Therefore, when enabling a Captive Portal for the first time in a new environment, it is key to communicate to end users to visit a particular website (perhaps the organization’s website as long as it is not HSTS) if they are unable to access the other websites. This will allow users to be redirected to a captive portal properly. Some organizations even setup a specific page for this purpose (onboard.company.com, register.company.com, etc) and notify users in advance.

Symptom 3

CWP redirection fails in environments using Proxy Server

Cause 3

Captive portals may not be able to provide proper redirection if internal hosts on the network are configured to use a proxy server.

Resolution 3

By making the proper proxy exceptions on your proxy server, this will ensure captive portal redirection functions properly.

See: Configuring Captive Web Portal for info on creating proxy server exceptions.