Everything You Need to Know About SSL Stripping Attacks & HTTP Strict Transport Secure
Introduction
In the last post, we learnt a lot about SSL/TLS (SSL certificates, SSL handshakes, and so on) and saw how important it is in safeguarding online communication and protecting sensitive data. But I stated that despite the secure connection established by the SSL/TLS protocol, this communication remains vulnerable to malicious attacks because it is over the internet. In this article we are going to talk about SSL attacks, especially the striping attack also known as SSL downgrade or HTTP downgrade attacks; we will cover everything you need to know.
Before I begin, let me discuss the internet vulnerability.
How is the Internet vulnerable?
Many early network protocols that now form part of the Internet infrastructure were designed without security in mind. This was mainly because cybersecurity was not a top priority at the time. Examples of such protocols include HTTP (Hypertext Transfer Protocol), which is used for web browsing, SMTP (Simple Mail Transfer Protocol), which is used for email, and FTP (File Transfer Protocol), which is used for file transfers. These protocols were originally developed with the assumption that all participants on the network were trustworthy, and did not include any mechanisms for authentication, encryption, or integrity protection.
The focus was primarily on making communication between computers possible, and security measures were often considered an afterthought. As a result, attackers can exploit these vulnerabilities to intercept, modify, or steal sensitive data and information.
To address these issues, newer protocols and security protocols such as SSL/TLS (Transport Layer Security), SSH (Secure Shell), and IPsec (Internet Protocol Security) have been developed to provide security services to Internet communications.
However, older protocols that were not designed with security in mind are still in use today, and many organizations continue to rely on them.
What is a network attack?
A network attack is an attempt to gain unauthorized access to an organization’s network, steal data or perform other malicious activity. There are two main types of network attacks:
Passive: Attackers gain access to a network and can monitor or steal sensitive information without making any changes to the data, leaving it intact.
Active: Attackers not only gain unauthorized access but also modify data, either deleting, encrypting, or otherwise harming it.
A Brief History of SSL Stripping
The SSL stripping vulnerability was discovered in 2009 by Moxie Marlinspike, a prominent American computer security researcher. He brought out details of how SSL stripping attacks can be executed without anyone ever noticing them making them a serious threat to the digital security of both regular users and businesses.
By the end of this article, you'll have a complete understanding of SSL stripping attacks.
What is an SSL stripping attack?
Every connection to a website requires an application protocol, which is either HTTP or HTTPS. HTTP is less secure. It transmits information in plaintext, whereas HTTPS is more secure because it encrypts all information.
SSL stripping attacks are a type of attack in which hackers downgrade a web connection from the more secure HTTPS (Hyper Text Transfer Protocol Secure) to the less secure HTTP (Hyper Text Transfer Protocol).
This attack occurs when the hacker intervenes in the communication as (a man-in-the-middle) between a user and the website server. The hacker sits in the middle of the connection, connecting himself to the target site and connecting the user to their servers. All the traffic from the victim’s machine is routed via a proxy server which is created by the hacker. This allows the hacker to see everything the user sends in unencrypted form.
How does an SSL stripping attack work?
When you type an address in your browser’s address bar, your browser first connects to the target site over an insecure connection (HTTP). The site then usually responds with a redirect to use a secure protocol (HTTPS) after the SSL handshake succeeds.I explain that in the last article.
What if :
There was a way to get around the SSL handshake?
- For example, attack the transition from the unsecured connection to the secure connection.
After inserting themselves in the connection and creating a proxy server, if the legitimate user attempt to connect to the legitimate website server, the user will establish a connection with the server fully controlled by the hacker. The hacker’s server then relays all traffic to the target website’s server and back, allowing the hacker to read and modify information along the way.
If the victim wants to use HTTPS when visiting the site, their browser will expect the attacker’s server to present an SSL/TLS certificate for the domain. This requires the attacker to generate a certificate for the target website server and send it to the victim’s browser.
After providing a certificate (fake) to the browser, another challenge is the Certificate Authority! Browser trusts in certificates signed by a trusted Certificate Authority (CA). If a certificate is not signed by a trusted CA, your browser will show a clear warning and may even refuse to open a page.
For this attack to succeed, hackers need to add their CA to the trusted certificate store in your operating system. This part has to be done through other attack vectors, such as HTTPS Phishing.
Scenario
In this scenario, the target site is the foobank.com website, and you are the victim.
The hacker makes a targeted phishing attack against you utilizing JavaScript-related vulnerabilities, causing you to download and install their CA certificate. This allows the hacker to generate TLS/SSL certificates that will be accepted by your browser without warning messages.
The hacker configures their web server to act as a proxy. It accepts all connections to foobank.com and relays them to the real foobank.com website, and does the same with all the responses from the foobank.com website to you.
Your computer is configured to use the DNS caches of your local provider. The hacker performs a DNS cache poisoning (DNS spoofing) attack against your provider’s DNS cache servers, causing your computer’s local cache to store the hacker’s IP address as the IP of foobank*.com*. Until this information expires in your local cache, you will be connecting to the hacker-controlled IP address every time you try to visit foobank.com in your browser.
Now, when you type *https//www.*foobank.com in the address bar, your browser looks up the IP address of *www.*foobank.com in your computer’s local cache and finds the hacker’s IP address. The browser then connects to the hacker’s server and accepts a fake SSL/TLS certificate for foobank.com. No warning is shown because the browser successfully verifies the fake SSL/TLS certificate using the hacker’s CA certificate installed earlier.
Your browser creates an SSL connection to the hacker’s server, and you now have secure, encrypted communications between your browser and the hacker’s server. However, all SSL traffic is decrypted by the hacker, logged and then separately relayed to the real foobank web server via a server-side secure connection. Neither you nor the foobank web server has any way of knowing that this is a MITM attack.
What is HTST?
HSTS stands for HTTP Strict Transport Security. It is a web security policy mechanism that helps to protect websites against various types of attacks, particularly those related to HTTPS downgrade attacks (striping attacks) and certificate forgery. It prevents hackers from intercepting web traffic and downgrading the connection to HTTP, replacing the secure HTTPS connection with an insecure one. Not only that, but it also protects against attacks where an attacker tries to use fraudulent or forged digital certificates to impersonate an HTTPS website. In the next section, we will see how HSTS aids in preventing SSL attacks.
How does HSTS aid in preventing attacks like SSL stripping attacks?
HTTP Strict Transport Security was defined as standard web security in 2012 in RFC 6797. The primary goal of creating this standard was to help avoid man-in-the-middle (MITM) attacks that use SSL stripping.
Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS.
When you type foobank.com in your browser and press enter, the browser will first try to use an HTTP tunnel and then the server will respond and redirect to an HTTPS tunnel if the SSL handshake succeeds. Hackers insert themselves in the communication when the tunnel is insecure (thus HTTP). So, if we can prevent the browser to use the HTTP tunnel, we can prevent hackers from inserting themselves in the communication as a man-in-the-middle.
The HSTS Policy is communicated by the server to the user agent (browser) via an HTTP response header field named Strict-Transport-Security
. HSTS Policy specifies a period during which the user should only access the server in a secure tunnel (HTTPS).
But this protection applies after a user has visited the site at least once, using the principle of "trust on first use". The way this protection works is that when a user enter or selects a URL to the site that specifies HTTP, the user will be redirected directly to HTTPS before requesting the website server, which prevents the HTTP man-in-the-middle attack from occurring.
The Strict-Transport-Security
header gives specific instructions to the browser.
A server sends a header field such that future requests to the domain for the next year use only HTTPS: Strict-Transport-Security: max-age=31536000
.
So, from now on, every connection to the site and its subdomains for the next year (31536000 seconds from the moment this header is received) must be an HTTPS connection. HTTP connections are not allowed at all. If the browser receives a request to load a resource using HTTP, it must try an HTTPS request instead. If HTTPS is not available, the connection must be terminated.
When a web application issues HSTS Policy to user agents, conformant user agents behave as follows :
Automatically turn any insecure links referencing the web application into secure links (e.g.
http://example.com/some/page/
will be modified tohttps://example.com/some/page/
before accessing the server).If the security of the connection cannot be ensured (e.g. the server's TLS Certificate is not trusted), the user agent must terminate the connection and should not allow the user to access the web application.
Conclusion
Both website owners and internet users must be aware of the potential threat posed by SSL stripping attacks and the importance of implementing HSTS (HTTP Strict Transport Security).
By enabling HSTS (HTTP Strict Transport Security) on websites, users' browsers are instructed to only establish secure TLS/SSL connections, thereby mitigating the risks of SSL stripping attacks. HSTS accomplishes this by informing the browser to remember and automatically upgrade any non-secure HTTP requests to HTTPS, ensuring end-to-end encryption.
I hope that the information I have shared has been informative, helpful and thought-provoking. I always strive to provide the best content possible.
Once again, thank you so much for reading. Your presence and support mean a lot to me!
Regards,