The steady growth in the use of encrypted communications seems likely to increase next year given recent announcements on both web browsers and servers. That’s good news for security people worried that their users may be sending sensitive information such as passwords and credit card numbers over the Internet. However it may also require an adjustment in where we concentrate our efforts to protect those users and their equipment.
For many years it’s been common to use content filtering technologies within organisational networks to detect and block both malware and undesirable content. However these are ineffective on encrypted communications as the same encryption that protects users’ privacy also protects these threats from being inspected and detected. Like any tunnelling technology, encrypting communications to a web server means that protection relies on the equipment at the end of the tunnel: normally the end user PC, laptop, tablet, etc. As the use of encrypted communications becomes more common, technical measures on those devices – such as patches, anti-virus and local firewalls – and safe behaviour by their users will be increasingly important. Fortunately devices are also becoming more powerful, capable of supporting more security features, and safe surfing is increasingly recognised as a critical life skill. We need to support and promote those trends.
Network-based measures are still available and useful. Infected or malicious websites can be blocked at DNS or IP level, whether their communications are encrypted or not. Whitelists of trusted websites will still work, too. Safe search can also be implemented using DNS and IP, as explained in Google’s post (see Option 3). Any unencrypted communications will still be available for inspection, of course.
If this is insufficient, it’s technically possible for an organisation to inspect content within its users’ encrypted tunnels, but there are significant technical, privacy and security disadvantages, as well as legal issues (interception, data protection and privacy) that need to be considered. Encryption relies on a matching pair of certificates – one at the server end, one in the user’s web browser. If the certificates do not match, most browsers will warn the user very loudly that they are under attack. Some systems may effectively refuse to proceed. Inspecting content inside the tunnel involves forging the server-side certificate, so the organisation must be able to reconfigure all its clients with the matching client-side certificate. This may be possible if all devices on the network are centrally managed but it is likely to make the network effectively unusable, and reported as extremely hostile, to any visiting or unmanaged devices.
Once the forged certificate is installed on a client machine, the organisation is likely to be able to decrypt all SSL/TLS-encrypted tunnels, including those used to transmit sensitive personal, financial or health data. The organisation must ensure their processes and technology (e.g. to prevent unauthorised or inappropriate access to the filtering device) are sufficient that that doesn’t become a serious privacy and security threat. Furthermore a client connected to an intercepting filter will no longer detect or report certificate errors, even if it accesses a malicious external site with its own forged certificate. The filtering device must recognise and block any certificate errors itself, otherwise it will expose its users to even greater risk.
While a few organisations may have the justification and ability to deploy intercepting filters, all should be taking steps to improve the security of their end devices and users. Unlike network-based measures, which only protect users when they are connected to that network, secure devices and users stay secure wherever they are and however they connect.
