Over the past few years, HTTPS interception has become extremely important. Without it, online safety systems are extremely limited in their ability to filter and record auditing data regarding secure websites. The way this works is relatively straight forward: the client asks the Iceni proxy to connect to a secure web site, Iceni negotiates a secure connection with the web server, copies the web server's certificate and uses it to negotiate the secure connection with the client. Of course, the copied certificate can't be signed with one of the "official" certification authorities, so Iceni signs it itself. This means that all of the client devices need to be told that Iceni is a trusted certification authority, and this is done by importing Iceni's interception certificate into the device's trusted certificate store. All of the software running on the device should use that certificate store when they are making secure connections so this always works perfectly...
Except, of course, it doesn't - most of the time it works perfectly, but there is a significant amount of badly behaved software around that doesn't use the device's certificate store, so won't trust certificates that have been signed by Iceni. When interception is used with such software, the software will usually reject the connection as untrustworthy. Either it will warn the user of a certificate error, or more commonly, it just silently fails and doesn't tell the user why! Secondly, some software pretends to be using the HTTPS protocol but then uses a completely different protocol instead - Iceni is expecting to communicate in one language but the application tries to talk to it in a completely different language that it doesn't understand.
When an application connects via the non-transparent proxy, it usually tells the proxy which host name it wants to connect to. Iceni has a built in list of domains that are known to be associated with badly behaved applications, and when it sees a connection to one of those domains HTTPS interception is automatically turned off. However, there are some common situations where this doesn't work:
- Some applications only give the proxy an IP address to connect to, not a host name.
- If the application is connecting through the transparent proxy instead of the non-transparent one, Iceni won't know the host name of the server being contacted.
- Some applications connect to generic host names within cloud services, such as Amazon AWS.
There is little that can be done to work around the third problem - this would require turning off HTTPS interception for the whole of the Amazon AWS cloud, for example, which is an unacceptable risk for most schools. However, we have been improving our HTTPS interception system to help with the first two problems, and this work is now being tested by our QA team prior to being rolled out to customers. We have introduced a passive HTTPS inspection stage, which the proxy can perform prior to doing full interception. So long as the client application has included a server name indication (SNI) in the secure handshake, Iceni can now extract the host name from a secure connection before intercepting it. It can then use the host name to selectively turn off HTTPS interception for certain domains, allowing the problem applications to connect.
An additional benefit of this change is improved auditing for "guest networks". A common configuration is for devices belonging to visitors to use the transparent proxy, and for HTTPS interception to be turned off entirely. This is very useful as it requires no configuration on the client device - no need to set a proxy or import a certificate. The down side has always been that, whilst Iceni could provide comprehensive filtering and auditing for HTTP traffic, it was not able to log or filter HTTPS accesses from these devices. Whereas now, the passive inspection stage can be used to provide an element of filtering and to collect an audit trail of HTTPS sites that are being accessed, even though full interception isn't being performed.