Closing the last door

There’s always a risk of viruses lurking behind links on a website. Even well-known sites can contain dangerous links, especially those with a high level of public interaction – forums, message boards, social networks and so on. Small and midsized businesses (SMBs) usually protect their data assets and staff with firewalls that include an integrated Web proxy and antivirus solution, known as Unified Threat Management (UTM) appliances. These are reliable at blocking viruses transmitted via ordinary HTTP. However, if the link URL starts with https:// instead of http:// the virus can be transferred via an encrypted connection, so it gets round the firewall and Web proxy without being detected.HTTPS proxies are the only way to ensure these viruses are blocked at the gateway.

If you’re working for a company that has a UTM appliance in place, you can be pretty sure that viruses are blocked at the gateway and never reach your PC while you’re surfing the Net. However, in some companies this can lead to a false sense of security, with the effect that the anti-virus software on the PC is either not kept up to date or hasn’t been installed at all. This can cause problems when someone visits a forum and clicks on one of the embedded links. It’s easy to miss the “s” in the URL. But the little “s” makes a big difference, as the URL is then loaded over an encrypted connection which can’t be checked by an ordinary firewall with a Web proxy. That’s how easy it is for – theoretically – protected PCs to become infected with a virus or worm. This is where the newest generation of UTM appliances comes in. They’re able to block this loophole too, by interrupting the encrypted connection with an HTTPS proxy. Let’s look at how this works.

An HTTPS connection is much more complicated than ordinary HTTP because its certificate-based encryption is built on top of a complex PKI. The identity of the destination server must be established before setting up an encrypted connection to it. On the internet, encryption only makes sense if the server’s identity has been confirmed, because otherwise a supposedly secure encrypted connection could be made with an unknown server. This could establish the connection to the target server while “eavesdropping” on the data being transmitted. Intercepting an encrypted connection like this is called a Man-in-the-Middle attack (MITM).

The identities of HTTPS servers are established using certificates that comply with the X.509 standard. Each HTTPS server has one of these certificates, which includes the owner’s name (the server’s domain), the validity period and a lot of other data. As almost anyone can create a certificate with any type of data they choose, the internet has its own authority that verifies that the data in the certificates is correct and only gives a digital signature to those that are valid.

These certification tasks are performed by several different companies, such as VeriSign, DigiCert, Deutsche Telekom and others. Every browser includes a list of certification authorities. In Firefox, for example, it can be found in Tools > Options > Advanced > Encryption > View Certificates > Authorities. Every Certificate Authority (CA) listed here is considered trustworthy for the browser concerned and is allowed to sign HTTPS server certificates.

1. The browser calls an HTTPS page. This may just be a link on a normal HTTP page.
2. The HTTPS server sends the browser its certificate. This certificate is created specially for this server and includes its name. An official CA has verified and digitally signed the certificate.
3. The browser compares the signature on this certificate with the list of trustworthy CAs, and the name of the server (domain) with the URL of the requested page.
4. If one of the listed CAs can vouch for the HTTPS server certificate and the certificate shows that the server corresponds to the one with the requested page, an encrypted connection is established with no error messages.

This HTTPS connection is securely encrypted and established directly between the browser and the HTTPS server. This situation makes it impossible for the firewall to scan the transmitted data for viruses.

The latest generation of UTM appliances tries to look for viruses everywhere, even within encrypted connections. To do this, they use a technique similar to one well known to hackers. With an MITM attack, the direct connection between the browser and the HTTPS server is divided into two parts, with the unencrypted – and readable – data sitting between the two. A firewall is usually located between the PC and the internet, so an MITM attack is always possible.

1. As before, the browser calls the URL of the HTTPS server but this time the connection is terminated by the HTTPS proxy.
2. The HTTPS proxy then initiates a connection itself to the target server.
3. The HTTPS server answers by sending its certificate to the proxy.
4. Just like the browser, the HTTPS proxy requires a list of trustworthy CAs so it can verify that it is really communicating with the requested HTTPS server. Using this list, the certificate sent in (3) is checked.
5. If the certificate is valid, the first encrypted connection is established between the HTTPS proxy and the HTTPS server.
6. The original connection initiated between the browser and the HTTPS proxy in (1) isn’t answered until all the above steps are complete. The HTTPS proxy now sends a self-created certificate which indicates that the owner is the HTTPS server and is not signed by an official CA. Instead, the HTTPS proxy has its own CA which signs the certificate it created.
7. This CA is, of course, not in the browser’s CA list, so the HTTPS page is only loaded after a security warning has appeared and asked for the user’s express permission to display it. To avoid that happening, the company’s IT administrator would need to copy the HTTPS proxy’s CA into the CA lists of all its browsers. However, this is easy to do in Windows environments with Windows Group Policy Management.
8. Once all this has been done, the second encrypted connection between the browser and the HTTPS proxy is established.

At this point, the data is sent by the HTTPS server to the HTTPS proxy, and as it is unencrypted it can be scanned there to check for viruses. If no threats are present, the data is sent to the browser via the second HTTPS connection. This method ensures that the data cannot be read – neither in the local network nor on the internet – but can be checked within the firewall and any viruses present can be blocked.

In this way, UTM appliances with an HTTPS proxy increase the security of company networks, because they close the last loophole that viruses have long been able to use to get into staff PCs. However, it’s important to emphasize that HTTPS is not necessarily the last non-secured entry point for the internet. There are many services that are no different to their unencrypted cousins except for the “s” in the name. These include the mail protocols POP3s, IMAPs and SMTPs which can be set up in any mail client. Here, too, an encrypted connection is established across the firewall so that viruses and worms can’t be detected.

There are other communication tools too – such as instant messengers and file-sharing programs – that may try to smuggle viruses through firewalls using encrypted connections. Keeping pace with all these developments is the main mission of current firewalls and security appliances. After all, companies can only really be confident about security if they can be sure they’re monitoring all the communication channels on their network.