Hypertext Transfer Protocol Secure (HTTPS) is widely known as the extension of the Hypertext Transfer Protocol (HTTP), used for secure communication over a computer network, and now commonly implemented across the internet. In a web browser such as Google Chrome, for example, a website that uses HTTPS is symbolized by a green padlock in the URL bar and is considered secure, whilst a website that does not use HTTPS is flagged as ‘not secure.’
HTTPS is encrypted to safeguard data transfer and it is broadly accepted that any website, especially those that require login credentials to be entered, should use HTTPS. It is designed to prevent websites having information broadcast in a way that’s easily viewed by anyone snooping on the network, and when you consider the sensitive nature of much of the data on the modern internet, that concept makes perfect sense.
However, whilst HTTPS is generally secure and certainly a better protocol than traditional HTTP, it is not perfect, with its own security gaps and pitfalls. In fact, as is the belief of Guru Pai, co-founder and CEO of Privafy, an overreliance on HTTPS can actually create significant security risks.
To find out more, Infosecurity spoke to Pai to explore the effectiveness, reliability and drawbacks of HTTPS.
How effective is HTTPS as a means of security?
From a security standpoint, HTTPS was designed to, and does a great job of, maintaining the content integrity of websites. It makes sure that bad actors can’t hijack a website or add unwanted content without approval.
Over time, HTTPS gained popularity as the website security protocol, mainly because of how easy it is to deploy and use. It can work anywhere on any device, as long as there is a browser and compatible server available.
However, there’s been a misconception that HTTPS is universally safe. Developers have moved beyond protecting just website content and started to rely on HTTPS to safeguard personally identifiable information (PII) and other sensitive business and customer data – and that needs to change.
What are the security risks surrounding HTTPS?
HTTPS relies on root certificates to authenticate a user’s device with the browser they’re trying to access and apps are special-purpose instances of browser technology. So, the applications and browsers we use daily rely on HTTPS as their primary security mechanism.
What most security teams don’t realize, though, is that the same root certificates used to authenticate a user’s device with the browser are really an ‘Achilles Heel.’ Compromised root certificates can provide hackers with all sorts of nefarious abilities.
Before we discuss those abilities, though, it’s crucial to understand how hackers can compromise root certificates in the first place. It comes down to three distinct vulnerabilities:
- Human error: Root certificates are installed either manually or mechanically, which means the individual human operating these systems can be compromised, either by having a key copied or stolen
- Device compromise: In some instances, a threat actor could sideload or, through some other channel, install bad root certificates directly on the device, providing hackers the ability to eavesdrop on devices
- Man-in-the-middle attacks: For this scenario, the certificates are intact on both sides to start. Yet, there’s a deep packet inspection (DPI) system in the path of the communication that intercepts the outbound certificate, terminates it, and re-originates a back-to-back session with a new certificate. In this case, the two endpoints don’t realize they’ve been compromised and continue to transmit the information while a hacker surveys in the middle unknowingly.
Historically, these types of attacks required a lot of specialized and expensive equipment. However, advances in technology and the rise of cloud computing has created cheaper and easier ways to compute so that these attacks can be launched in a lot of different environments for a lot of applications with relative ease.
How can HTTPS be exploited by cyber-criminals?
Performing any of the acts above allows hackers to do a few things, including hijack data and hold it for ransom, steal intellectual property or use the compromised root certificate as a way to inject malware into an enterprise.
For example, when you look at high-value consumer verticals that rely on applications to connect with customers, like banking, gambling, financial or healthcare, you can understand how a hacker could use any one of HTTPS’ vulnerabilities to capture personally identifiable data.
Another way cyber-criminals can exploit HTTPS is by performing a Man-in-the-Middle attack to listen in on communications and steal intellectual property.
Finally, while employees rely on SaaS applications to remain productive while away from the office, there are malicious actors that want to harm the company; these actors could want to carry out either opening the doors for another attack, injecting malware into the organization, or flooding the system with DDoS attacks. A compromised root certificate enables a cyber-criminal to do all three of these attacks with ease.
How can website security be improved?
Security experts are starting to recognize that HTTPS is flawed and are taking the necessary steps to remediate the issue. However, most work has been focused on either increasing encryption by using better algorithms or creating physical keys.
Yet, increasing the number of bits for encryption doesn’t solve the problem. Resolving HTTPS’ vulnerabilities comes down to making sure keys aren’t compromised, not the quality of the encryption.
While physical hardware keys are another approach that has gained some traction to improve website and application security, it’s incredibly unwieldy, hard to implement on mobile devices, and adds another layer of complexity to security practices. In fact, the key itself can be stolen, which introduces a whole different range of problems.
Finally, we’re also seeing organizations trying to stop keys from being compromised by layering in VPNs below HTTPS to secure the connection. That said, the security of a VPN has vulnerabilities that have yet to be fixed. So while VPNs are attempts to fix the well-known compromise of credential vulnerabilities, they bring their own security and implementation challenges.
A far better way to prevent hacks, while taking advantage of the ubiquity of HTTPS, is to ensure that there aren’t physical static keys being provisioned into these systems.
Security teams need to start thinking about dynamic key and credential management. With this approach, those keys can be changed on a per session basis, there is no cost, and the complexity of physically changing the keys at all the endpoints and keeping them in sync. You also eliminate man-in-the-middle-attacks because the keys are being continuously rotated. With this approach, you get the flexibility of HTTPS but with the higher security standards of ensuring key compromises never happen.