Everything You Need to Know About SSL Stripping attacks & HTTP Strict Transport Secure

CREDO23 - Jul 5 '23 - - Dev Community

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 talks 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.

šŸ’” As new technologies and applications are being developed, new vulnerabilities and attack vectors emerge, which makes it difficult for security experts to keep up and protect against all potential threats. That is why the internet remains vulnerable.

What is a network attack?

image that describe a network attack

A network attack is an attempt to gain unauthorized access to an organizationā€™s network, with the objective of stealing data or performing 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 striping attacks.

Letā€™s goo

Letā€™s goo

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 because 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 that is created by the hacker. This allows the hacker to see everything the user sends in unencrypted form.

šŸ’” A proxy server is a server that acts as an intermediary between a client (such as a user's computer) and other servers on the internet. The client sends its requests to the proxy server, which in turn forwards them to the appropriate servers, and vice versa.

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.

What if :

  • There were a way to get around the SSL handshake ?
    • For example, attack the transition from the unsecure connection to the secure connection ?

a way to get around the SSL handshake?

Yes ! It is possible and that is what we call SSL Stripping attack !

man in the middle attack (ssl stripping)

Once hackers have got the traffic (the handshake session), they create a fake valid certificate, mimicking the target web server. To do that, hackers use another type of man-in-the-middle attack to intercept the connection between the legitimate user and the legitimate server, for example ARP spoofing, IP spoofing or DNS cache poisoning.

After inserting themselves in the connection and create 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.

šŸ’” Operating systems such as Microsoft Windows and Linux come with a built-in set of trusted Certificate Authorities, but you can always manually add new ones.

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 is theĀ foobank.comĀ website, and you are the victim.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 have any way of knowing that this is a MITM attack.

šŸ’” Unfortunately, after inserting their own certificate in your computer by HTTPS Phishing, browsers wonā€™t display any SSL Certificate warning pop-ups, and the victims have no clue that such an attack is going on ā˜¹.

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

HTTP Strict Transport Security was defined as a 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 SSL handshake succeds. Hackers insert themselves in the communication when the tunnel is ensecure (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 of time 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 select a URL to the site that specifies HTTP, the user will be redirected directely to HTTPS before making a request to the website server, which prevents the HTTP man-in-the-middle attack from occurring.

šŸ’” Trust on first useĀ (TOFU), orĀ trust upon first useĀ (TUFU), is anĀ authentication scheme used by client software which needs to establish a trust relationship with an unknown or not-yet-trusted endpoint. In a TOFU model, the client will try to look up the endpoint's identifier, usually either theĀ public identity key of the endpoint, or the fingerprintof said identity key, in its local trust database. If no identifier exists yet for the endpoint, the client software will either prompt the user to confirm they have verified the purported identifier is authentic, or if manual verification is not assumed to be possible in the protocol, the client will simply trust the identifier which was given and record the trust relationship into its trust database. If in a subsequent connection a different identifier is received from the opposing endpoint, the client software will consider it to be untrusted.

TheĀ Strict-Transport-SecurityĀ header gives specific instructions to the browser.

A server send 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 :

  1. Automatically turn any insecure links referencing the web application into secure links (e.g.Ā http://example.com/some/page/Ā will be modified toĀ https://example.com/some/page/Ā beforeĀ accessing the server).
  2. 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.

šŸ’” This will work only if the hacker didnā€™t strip the header on the first visit to the site.

This will work only if the hacker didnā€™t strip the header on the first visit to the site.

Conclusion

It is crucial for both website owners and internet users to 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 you found the information I provided to be useful. I constantly make an effort to deliver the highest quality information.

I want to thank you one again for reading. I much appreciate your support and being here!

Regards,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .