Are you undermining your web security by checking on it with the wrong tools?
Probably yes, warns US-CERT in HTTPS interception advisory
Your antivirus and network protection efforts may actually be undermining network security, a new paper and subsequent US-CERT advisory have warned.
The issue comes with the use of HTTPS interception middleboxes and network monitoring products. They are extremely common and are used to check that nothing untoward is going on.
However, the very method by which these devices skirt the encryption on network traffic through protocols like SSL, and more recently TLS, is opening up the network to man-in-the-middle attacks.
In the paper [PDF], titled The Security Impact of HTTPS Interception, the researchers tested out a range of the most common TLS interception middleboxes and client-side interception software and found that the vast majority of them introduced security vulnerabilities.
"While for some older clients, proxies increased connection security, these improvements were modest compared to the vulnerabilities introduced: 97 per cent of Firefox, 32 per cent of e-commerce, and 54 per cent of Cloudflare connections that were intercepted became less secure," it warns, adding: "A large number of these severely broken connections were due to network-based middleboxes rather than client-side security software: 62 per cent of middlebox connections were less secure and an astounding 58 per cent had severe vulnerabilities enabling later interception."
Of the 12 middleboxes the researchers tested – ranging from Checkpoint to Juniper to Sophos – just one achieved an "A" grade. Five were given "F" fail grades – meaning that they "introduce severe vulnerabilities" – and the remaining six got "C" grades.
Likewise, of the 20 client-side pieces of software from 12 companies, just two received an "A" grade: Avast's AV 11 for Windows (not Mac), and Bullguard's Internet Security 16. Ten of the 20 received "F" grades; the remaining eight, "C" grades.
How does it happen?
TLS and SSL encrypt comms between a client and server over the internet by creating an identity chain using digital certificates. A trusted third party provides that certificate and it verifies that your connection is to a trusted server.
In order to work, therefore, an interception device needs to issue its own trusted certificate to client devices – or users would constantly see warnings that their connection was not secure.
Browsers and other applications use this certificate to validate encrypted connections but that introduces two problems: first, it is not possible to verify a web server's certificate; but second, and more importantly, the way that the inspection product communicates with the web server becomes invisible to the user.
In other words, the user can only be sure that their connection to the interception product is legit, but has no idea whether the rest of the communication – to the web server, over the internet – is secure or has been compromised.
And, it turns out, many of those middleboxes and interception software suites do a poor job of security themselves. Many do not properly verify the certificate chain of the server before re-encrypting and forwarding client data. Some do a poor job forwarding certificate-chain verification errors, keeping users in the dark over a possible attack.
In other words: the effort to check that a security system is working undermines the very security it is supposed to be checking. Think of it as someone leaving your front door wide open while they check that the key fits.
What's the solution? According to US-CERT, head to the website badssl.com to verify whether your inspection product is doing proper verification itself. And of course, check out the SSL paper and make sure you're not running any of the products it flags as security fails on your network. ®
Sponsored: Becoming a Pragmatic Security Leader