This section of the guide is intended to give a general overview of web access management, filtering and related concepts. These high-level concepts will inform how you can best deploy LiveStream 5 to fit the types of users and devices within your organisation.
The LiveStream 5 software manages web access for clients via a proxy service which clients connect to in order to access the web.
A proxy is an intermediary server that performs web requests on behalf of client computers that connect with it, and in having this responsibility is able to manage those web requests based on many different factors. Once a proxy server is deployed within an organisation, the client computers (or any devices with a web browser) must be configured to use it. There are several different ways to do this, some of which are more convenient than others depending on the network environment.
System administrators can make it effectively impossible to bypass a proxy as long as they have these two things:
An organisation can configure their network so that only select servers (including the proxy) can access the internet directly. This forces all client computers to use the proxy or not access the web, full stop. We suggest configuring the outbound rules on your gateway/firewall for your client computers as follows:
A common vector for bypassing filtering is Anonymous Proxy websites. It's important that any system aiming to restrict web access is able to block as many of these sites as possible. In addition to filtering millions of known Anonymous Proxies, LiveStream 5’s category filtering can also identify and categorise new Anonymous Proxies instantly.
BYOD (Bring Your Own Device) refers to programmes which allow students and/or staff to bring their own personal mobile devices to campus (or workplace) and connect them to the organisation’s network facilities in order to access the internet etc.
Unlike organisation-managed devices these mobile devices can’t necessarily be forced to have a proxy configured. The organisation may set their network up to block access for anybody who is not using the proxy but that still leaves these two problems:
It’s not very convenient for non-technical users to have to manually configure their proxy settings when they join a school network.
Many mobile applications do not have adequate compatibility with proxies.
All of the following options are available in LiveStream 5.
WPAD (Web Proxy Auto-Discovery Protocol) provides a method by which client devices may obtain a Proxy-Auto Configuration script (or PAC file) automatically via DNS or DHCP.
Deploying WPAD within a network ensures that whomever connects to the network (and has their device set to "auto-configure proxy settings") will have their proxy settings automatically configured.
This is generally the preferred way to solve Problem #1.
The basic steps for deploying WPAD are as follows:
wpad.dat.ProTip: There's a wealth of information, instructions and examples at http://findproxyforurl.com.
Keep in mind that — because this configures the clients' proxy explicitly — it will not work-around Problem #2: proxy incompatibility among certain applications.
An intercepting proxy, otherwise known as a transparent proxy or forced proxy, is able to pretend that it is a standard internet gateway. In actuality, while it does route the traffic, it also intercepts it into the proxy for inspection and management.
By behaving as a router the intercepting proxy can be set as a client device’s default gateway which can be set automatically when the device joins the network via DHCP. This solves Problem #1.
Additionally, because the client web applications are able to communicate as they normally would with a default gateway, they don’t have to be especially compatible with proxies. Any web-enabled app will work. This solves Problem #2.
Heads up! LiveStream 5 will intercept web traffic on port 80 and 443 as well as accepting explicit proxy connections on the standard proxy port. This allows you to choose the right connection method for each type of device.
In solving these two problems we now have a network environment that’s very convenient for students and staff to turn up with a personal device, join the WiFi and be browsing the web straight away, but still have their web access finely controlled by the organisation.
Intercepting proxies do however have a caveat of their own...
The HTTPS protocol uses SSL to establish a secure communications tunnel directly from the client device to the website. Many sites use this for security purposes, particularly where usernames and passwords are being exchanged or other sensitive personal information.
When the client web browser is configured to use a proxy, they can exchange certain information so that the proxy is able to record which hostname the client is establishing the SSL tunnel with (the hostname is not encrypted). However, if the browser is communicating via an intercepting proxy, this cannot happen because the browser is unaware of it.
This leaves the administrator of the intercepting proxy with three options:
Ignore HTTPS traffic and allow all client access to HTTPS websites directly: The obvious problem here is that the students will be able to access the HTTPS versions of websites that would ordinarily be blocked on HTTP such as Facebook, Twitter and YouTube. Not very viable.
Ignore HTTPS traffic and deny all client access to HTTPS websites: This isn’t really viable for most organisations, either, seeing as many popular services rely on HTTPS. Things like online banking, almost every web-based login page, even Google searches now default to HTTPS.
Intercept HTTPS connections and decrypt them: While this is technologically achievable it is a fundamental violation of the protocol and the user’s expectation that the encrypted web requests they make will be private. But despite this, it tends to be the preferred option out of the three because it is (or can be) more convenient for end-users and will also allow the organisation to manage the traffic.
Heads up! In order to implement option #3 without triggering web browser warnings, the client devices have to trust the proxy's authority to sign the SSL certificate of any website by installing the proxy's self-signed CA certificate.
LiveStream 5 makes HTTPS interception as simple as possible with features such as: