Introduction
SSL Stripping is an attack used to circumvent the security provided by HTTPS connections between the users and the HTTPS enabled websites. This attack is also known as SSL Downgrade Attack, since it downgrades secure HTTPS connections to HTTP and exposes the traffic exchanged in clear text (unencrypted) to eavesdroppers.
The attack not only allows the attackers to capture any sensitive information transferred, but also gives the attackers full capability to manipulate the content of the packets transferred. This attack is considered to be relatively easy for the attackers to conduct and extremely dangerous for the users since it could cause great damages for the careless users.
It was first demonstrated by Moxie Marlinspike at Black Hat DC with a tool named as SSLStrip in 2009. In essence, this tool would intercept HTTP traffic made by the users and strip HTTPS transparently upon detecting HTTPS redirect messages from the web server.
Background
The naming of SSL stripping may actually mislead to an understanding that this attack can only be conducted for the SSL (Secure Socket Layer) connections. However, SSL stripping attack is effectively relevant for the TLS (Transport Layer Security) connections as well.
To give a quick overview on SSL/TLS, Netscape was the first web browser to incorporate a security solution in response to the security assurance need due to the increasing commercial usage over the Internet. As a result of this effort, the first version of SSL (Secure Socket Layer) was created in 1994. However, due to critical security flaws, this protocol was incrementally updated to SSL 2.0 and 3.0 versions to provide better security. This improved and more reliable security need eventually led to the creation of the TLS (Transport Layer Security) protocol in 1999. Today, TLS 3.0 is regarded as secure and used on most web sites when an HTTPS connection is established.
At a high level, HTTPS (HTTP over TLS) provides security through encryption that ensures not only privacy but also integrity for the web users. In other words, HTTPS both thwarts attackers from reading the making changes to the communication made between the web browsers and the web servers.
How The SSL Stripping Attack Works?
There are eight main stages to conducting SSL stripping on a web site that supports both HTTP & HTTPS connections.
Stage 1
The user makes an unencrypted HTTP GET request to a web site, such as https://cybersophia.net in our example scenario.
Stage 2
The attacker sitting in the middle of the conversation intercepts this initial request and simply forwards it to the web server without changing the content of the message.
Stage 3
The web server responds back to the user to make a secure HTTPS request rather than the insecure HTTP request. The response that the web server makes for this purpose is known as an HTTPS redirect message. In our example scenario, the server sends an HTTPS redirect message (301 Moved Permanently), such as https://cybersophia.net.
Stage 4
At this point, the attacker intercepts the HTTPS redirect message made by the server and prevents it from reaching to the user. Instead, the attacker impersonates the user and makes an HTTPS GET request as demanded by the web server. According to our example scenario, an HTTPS GET request, such as https://cybersophia.net is sent to the web server.
Stage 5
Thinking that the HTTPS GET request is coming from the user, the web server sends back an HTTPS 200 OK message to confirm the establishment of a secure HTTPS connection between the user and the web server.
Stage 6
The attacker again captures this confirmation message (200 OK) for the establishment of a secure channel between the user and the web server. This time, the attacker removes the security layer (SSL/TLS) on the message and forwards it back to the user. As a result, a secure HTTPS connection is established only between the attacker and the web server while an insecure HTTP connection is maintained between the user and the attacker.
Stage 7
The unsuspecting user receives the HTTP 200 OK message sent by the attacker, thinking that the HTTP GET request made at Stage 1 has been confirmed by the web server.
Stage 8
For the rest of the communication between the user and the web server, the attacker can effectively intercept, read or manipulate everything being communicated, without any indication to the user or the web server.
The SSL stripping attack stages described above is illustrated with an example scenario in Figure 1.
Evaluation of the SSL Stripping Attack
As can be inferred from the explanations made above, this attack can not be used to downgrade any HTTPS connection. Rather, there are some conditions that must hold true to allow an attacker to conduct this attack successfully.
- First, the web server must support both HTTP & HTTPS protocols.
- For the second and the essential requirement, the user must initiate the web connection request with HTTP protocol, rather than the HTTPS. Actually, hackers take advantage of this opportunity window to start the attack.
- For the third and the last criterion, the web server must be configured to make HTTPS redirect requests in response to insecure HTTP connection requests made by the users. If the web server does not redirect the HTTP requests to HTTPS and continues with the original HTTP request, the communication between the user and the web server can be intercepted and manipulated by any malicious third party as it takes place in clear text. However, this would constitute an ordinary man-in-the-middle (MITM) attack, rather than the SSL stripping.
Note that, so far we have made the implicit assumption that a secure HTTPS protocol, such as TLS 3.0, is being used between the user and the web server. Instead, if an insecure protocol is used for the HTTPS connection, an attacker can effectively conduct SSL stripping attack even when the initial request is made by the user is in HTTPS.
The magic of SSLStrip was that whenever it would spot a link to a HTTPS webpage on an unencrypted HTTP connection, it would replace the HTTPS with a HTTP and sit in the middle to intercept the connection. The interceptor would make the encrypted connection to back to the web server in HTTPS, and serve the traffic back to the site visitor unencrypted (logging any interesting passwords or credit card information in the process).
How to Avoid SSL Stripping Attacks?
Obviously, the best countermeasure to prevent SSL strippings attacks is to make the first request to the web server in HTTPS, using a secure protocol such as TLS 3.0. So, the users can be trained not to use HTTP when browsing the Internet. However, humans err and even if they wouldn’t, it would not be possible to train all the web users. Thus, an automated security mechanism needs to be implemented to provide a more reliable solution.
Do not expect users to make the security decisions that the system designers cannot make.
M. Uğur Aksu
Read more educational and inspirational cyber quotes at our page 100+ Best Cyber Security & Hacker Quotes.
For this purpose, initially a protocol called HTTP Strict Transport Security (HSTS) was created in 2012 (RFC 6797) in response to SSL stripping attacks. The protocol works by the server responding to the client to use HTTPS the next time a connection is made to the same web server by that web browser. This mechanism obviously provided an effective mitigation for the SSL stripping attacks.
However, the HSTS protocol had still a major shortcoming that allowed the attackers an attack window. This attack window is the very first connection that is made in HTTP to a web site. In this case, the user wouldn’t have received the HSTS rule that enforce HTTPS in the subsequent connections.
To help with the shortcomings of the HSTS, HSTS Preload Lists was proposed as a potential solution. HSTS Preload Lists works by hardcoding a list of websites for which the connections shall be only made using only HTTPS. Though this solution proves to be effective theoretically, it requires the additional effort of submitting web URLs to HSTS Preload List repository manually. For instance, https://hstspreload.org is an online service to submit domains for inclusion in Chrome’s HSTS preload list.
As an another mitigative measure, third party add-ons such as HTTPS Everywhere can be used to prevent web browsers from making any HTTP connections. HTTPS Everywhere can be installed on any major web browsers (Chrome, Firefox, Edge, Opera), and it comes installed by default in Tor and Brave browsers. In this case, users should ensure that HTTPS Everywhere is not disabled and reenable it after visiting sites that serve only HTTP content. Figure 2 displays a screenshot of the HTTPS Everywhere extension on the Tor Browser.
One last countermeasure to prevent SSL strippings attacks is the efforts by the web browsers to improve the users notifications warning that the current connection is being made in HTTP rather than the HTTPS and as a result their communications could be captured, read or altered. Thus, wary users can notice that they are connected thought the unencrypted HTTP protocol rather than the HTTPS, when checking the browsers’ address bar.
Final Remarks
In this blog post, we have discussed the simple yet dangerous mechanism of the SSL stripping attacks and provided an overview of the proposed solutions to thwart these attacks. Hackers take advantage of a single attack window that is caused by users making the initial request in HTTP instead of the secure HTTPS protocol.
As a mitigation, HTTP Strict Transport Security (HSTS) could be implemented by on the server side, as well as the HSTS Preload Lists that could be hardcoded at the browsers. Browser extensions such as HTTPS Everywhere can be installed on the browsers to prevent users from making HTTP connections at the first place. Lastly, efforts on improving the noticeability of the browser warnings on insecure HTTP connections could help users to avoid falling victims of SSL stripping attacks.
You could also read our popular articles What is a Security Vulnerability? or What is Vulnerability Scanning?
