Stripping away the encryption offered by HTTPS, called SSL Strip, is a serious cyber threat to many corporations since their employees are constantly on the move and require access to Internet on-the-go even through open non-secure Wi-Fi hotspots. Once attackers gain access to a network, they can act as a Man-in-the-Middle (MITM) to intercept connections over the network. These interception tactics can also be deployed against wired networks, provided that someone gains access to an Ethernet port.
The KRACK Attack effectively demonstrated that corporate users can’t blindly trust the medium that connects them to the internet. It also illustrates how encryption can be completely stripped away even if the site supports HTTPS.
The creator of SSL strip vulnerability is Moxie Marlinspike, a well-known American computer security researcher. In 2009, he spoke about this dangerous SSL weakness for the first time at the Black Hat information security event. According to Marlinspike’s presentation, the exploitation of this vulnerability is very serious threat for the privacy of our digital credentials since it can happen in real time, undetected, and targets whatever secure sites people are browsing to at any moment. It doesn't require multiple certificates and once the attacker gets his “dirty work” done, he can switch the victims back to a normal traffic stream.
HTTP and HTTPS are the application-layer protocols in a TCP/IP model, as illustrated in the figure below. HTTPS uses a secure tunnel to transfer and receive data which is commonly called SSL/TLS (Secure Socket Layer / Transport Layer Security), and therefore the suffix ‘S’ is added to HTTPS.
SSL/TLS is a secure protocol used to communicate sensitive information. This protocol is used when exchanging sensitive data such as banking information and email correspondence for example. The protocol’s security is established by creating an encrypted connection between two parties (usually a client application and a server). Browsers and web servers regularly use this protocol when a secure connection is needed. In most scenarios the following events take place when establishing a secure connection:
This process provides a reasonable guarantee of both privacy and integrity. In other words, we don't just encrypt the messages we're sending, we make sure the message we receive isn't altered over the wire.
In order to “strip” the SSL, an attacker intervenes in the redirection of the HTTP to the secure HTTPS protocol and intercepts a request from the user to the server. The attacker will then continue to establish an HTTPS connection between himself and the server, and an unsecured HTTP connection with the user, acting as a “bridge” between them.
How can the SSL Strip trick both the browser and the website’s server? The SSL Strip takes advantage of the way most users come to SSL websites. The majority of visitors connect to a website’s page that redirects through a 302 redirect, or they arrive on an SSL page via a link from a non-SSL site. If the victim wants, for instance, to buy a product and types the URL www.buyme.com in the address bar, the browser connects to the attacker's machine and waits for a response from the server. In an SSL Strip, the attacker, in turn, forwards the victim’s request to the online shop’s server and receives the secure HTTPS payment page. For example https://www.buyme.com. At this point, the attacker has complete control over the secure payment page. He downgrades it from HTTPS to HTTP and sends it back to the victim’s browser. The browser is now redirected to http://www.buyme.com. From now onward, all the victim’s data will be transferred in plain text format, and the attacker will be able to intercept it. Meanwhile, the website’s server will think that it has successfully established the secure connection, which indeed it has—but with the attacker’s machine, not the victim’s.
SSL Strip attacks can be implemented in a number of ways. The most common method is by creating a hotspot and allowing the victims to connect to it. Many attackers establish fake hotspots with names similar to legitimate hotspot names, for example, “Starbucks Coffee” instead of “Starbucks”. Unaware, the user connects to the malicious hotspot. Once the user tries to connect to the server, the attacker uses his control over the hotspot and attacks the user.
After the successful implementation of an SSL strip attack, the victim’s information is transferred in plain text format and can be easily intercepted by anyone, including the attacker. This results in a breach in the integrity and confidentiality of personal identifiable information (PII) such as login credentials, bank accounts, sensitive business data, etc. Hence the threat of this vulnerability is easily understood and may have varying implications to your digital presence. Your business relies on encrypted communications to transact securely across the edge to the endpoint. But what if you can’t trust the identifying certificates on each end of the channel? Without this trust, you can’t engage in e-commerce web transactions and online banking that your consumers now rely on without having a second thought about security.
SSL stripping attacks can work only on websites that encrypt only their login page. Hence, websites that use both HTTP and HTTPS in their setup are vulnerable to SSL stripping attacks. The question to be answered now is this: what can we do to secure ourselves against this threat? Is the adoption of HTTPS and the Chrome updates a panacea?
To mitigate this threat, financial institutions and technology firms have already enabled HTTPS on a site-wide basis. Enabling HTTPS encrypts the connection between a browser and the website, thereby securing sensitive data transmissions. Therefore it makes perfect sense for banks and high-profile technology firms to enable HTTPS on their dynamic websites because of the transaction of important and sensitive information.
We have also to realize that it is of equal importance to enable HTTPS across static websites, even if there aren’t any sensitive data transactions. A lot of corporations purchase an SSL certificate and they only configure the pages to be served over HTTPS that require a user to transmit personal information, such as login screens and checkout pages. That’s not a good way to operate.
Because of the abstract nature of internet connections, people think that a connection to a static website is secure over HTTP. However, the traffic travels through many points to get from your browser to a website. HTTP is insecure and allows anyone to manipulate traffic at any point between a laptop and a website. Attackers can intercept a lot of information by manipulating traffic on a static website protected only by HTTP. Some of it can be relatively harmless but other abuses are much more serious. But none of these abuses are possible if a site is protected by HTTPS. If there is any problem, web browsers like Chrome and Firefox display a message that warns visitors that they cannot verify the site’s TLS certificate.
So here is the first benefit for organizations. Trust. Encryption is like multifactor and security of the end user, but it also means that users can place greater trust in a website’s safety and authenticity. SSL/TLS is a solid way to endorse just how safe your platform is, adding a touch of professionalism to any site using it.
In addition, enabling HTTPS on a site-wide basis maintains compliance with all data privacy regulations, such as GDPR or NIST SP 800-122. Especially, GDPR clearly states that organizations must be able to provide “sufficient guarantees to implement appropriate technical and organizational measures” to ensure that processing of personal data will comply with the GDPR and that data subjects’ rights are protected. It’s a win-win situation.
Another (hidden) benefit is Google’s SEO ranking. Some companies spend a ton of resources on SEO without realizing that simply enabling SSL can give their site a ranking boost on Google Search. In 2014, when the browsers were still incentivizing SSL instead of mandating it, Google announced it was making HTTPS a signal in its ranking algorithm. Experts estimate that having SSL/TLS can give your website up to a 5% boost. Now let’s think about what happens to that ranking signal after everyone starts to migrate to HTTPS. It becomes a standard, and the boost functionally begins to flip, to change from a benefit for sites that have it to a penalty for sites that don’t. When everyone ranks 5% higher than you, you’re at a disadvantage.
In addition to enabling HTTPS on a site-wide basis, corporations should weigh the benefits of enabling HSTS (HTTP Strict Transport Security), which is a web security policy mechanism that helps to protect websites against SSL stripping attacks and cookie hijacking. It allows web servers to declare that web browsers should interact with them using only secure HTTPS connections, and never via the insecure HTTP protocol.
When a web application issues HSTS Policy to user browsers, conformant user browsers will automatically redirect any insecure HTTP requests to HTTPS for the target website. In addition, when a man-in-the-middle attacker attempts to intercept traffic from a victim using an invalid certificate, HSTS does not allow the user to override the invalid certificate warning message. By having a HSTS policy installed, it will be nearly impossible for the attackers to intercept any information at all!
In addition to enabling HTTPS on a site-wide basis and enforcing HSTS policy, corporations need to activate one last line of defense. They need to take proper safeguards to defend their SSL/TLS certificates against bad actors who could misuse the certificate. An important part of this process involves investing in a machine identity management solution such as Venafi Trust Protection Platform that allows organizations to continuously monitor their digital certificates for signs of abuse. Venafi Trust Protection Platform gives you the visibility you need to block a new breed of hackers who misuse keys and certificates to hide in your encrypted traffic. Plus, you’ll have what it takes to act quickly, when needed, to keep avoid compromise or disruption caused by expired certificates.
(This post has been updated. It was originally published on July 22, 2020.)