HTTPS Visibility in Healthcare and Corporate Networks

By Michael Adjei (MSc), Nuvias Cyber Security. 

Protecting the modern network with the traditional Proxy and IDS mentality of the late 1990’s and early 2000’s is not appropriate anymore. More and more attacks now use encrypted connections to try and conceal data exfiltration. The Dark and Deep (encrypted) webs as we know them now were not as prevalent in the past. Modern cyber-attacks are increasingly utilising the application layer as a vector over HTTPS connections.

Without adequate content inspection, attacks such as downloading malware from a phishing site via clear text communications over HTTP can be easily detected and stopped but there will be no visibility for SSL encrypted traffic, specifically HTTPS. For the majority of vendors, the basic steps for inspecting HTTPS web traffic will be as follows:

1. Enable SSL Inspection at the Perimeter device e.g. Firewall or Web Proxy
2. Firewall performs man-in-the-middle interception between the client and the Server
3. Firewall inspects the content of the now decrypted traffic against enabled protections
4. Firewall re-encrypts the connection

Issues with SSL Inspection

The steps described above seem simple except for one problem that always comes up irrespective of the security vendor – browser certificate errors and broken connections. As shown below, users will begin to see browser certificate warnings even for legitimate HTTPS connections.

Fig 1: Certificate error warning in Internet Explorer

A major reason for this is that the Firewall device re-encrypts and re-signs the connection with its self-signed certificate which will not be present by default in the Trusted CA Certificate Store of the browsers. Modern browsers have built-in tamper-evident security to check for situations where certificates are not signed by well-known Certificate Authorities (CA).

Fig 2: Trusted CA Store in Internet Explorer

Most Firewalls or perimeter devices ship with default self-signed CA certificates so the SSL certificate presented after re-encryption of the connection will not be trusted by modern browsers. In most networks, this is likely to generate a large volume of technical support calls. There is therefore the need to do some preparatory work before enabling the SSL inspection feature.

Preventing Browser Certificate Errors

To solve this, there are two main approaches that can be employed:

1. Import the Firewall CA Self-Signed certificate into every user’s browser root certificate store

(In Internet explorer, this can be done using Group Policy)

2. Purchase and import a recognised CA signed certificate (sub-CA) into the Firewall to be used for re-signing (public CA will already be trusted in modern browsers)

Special Considerations for Healthcare and Sensitive Networks

Although the following section applies to all other networks, Healthcare networks in particular have added considerations. As an example, they contain specialised medical equipment that may use formats and standards such as PACS and DICOM. These systems hold personal information and in some cases, are life supporting. They should therefore be protected as a priority. Prior to enabling SSL inspection across a network, it is important to consider the following:

1. Performance impact – SSL inspection introduces considerable load (Healthcare networks tend to have large number of network devices)
2. For easy classification, group specialised medical systems e.g. by their IPs or subnets
3. Configure exceptions for non-user systems and specialised equipment grouped above
4. Configure exceptions for trusted locations such as online banking and health related sites
5. Choose an appropriate option to prevent browser certificate warnings
6. Start with a controlled roll out to a select group of machines before network-wide roll out

To reduce disruption, the classification and exceptions detailed above (steps 2 – 3) should be put in place prior to enabling HTTPS or SSL Inspection across the network. Some of the most common protections employed for which SSL inspection may be required include Web or URL Filtering, Intrusion Prevention System (IPS), Heuristics & Sandboxing and other content inspection protections over SSL. These should be enabled to utilise SSL encryption.

To conclude, it is important to note that there are legal and personal privacy implications associated with SSL inspection. These concerns should be properly addressed in the Corporate Security Policy document for the organisation. Users and employees should also be made fully aware where the organisation is inspecting SSL traffic. Overall, SSL inspection is a vital tool in protecting a network when used for the right reasons and in the right way.