Udemy Free

What kind of attacks does SSL prevent?

December 27, 2023

SSL & TLS are protocols that are used for the encryption of communication channels between network devices. SSL & TLS are used to bind the identities of systems, users, websites, etc., with the help of digital certificates. These digital certificates are either issued by internal trusted certificate authorities or public Certificate authorities. Internal certificates are trusted between networking devices within enterprise while public certificates are trusted by networking devices across the globe.

These certificates hold identities of end entities and contains a cryptographic key pair consisting a pair of public and private key. Public key is distributed along with the certificate whereas private keys are kept secured by the entities. A network channel is encrypted using these key pair which ensures that data communicated between these network devices are secured from tampering or altering.

However, with all these security in place there are always vulnerabilities, technology and process gaps that enable hackers to exploit and steal the data. In this blog we are going to discuss some of the SSL/TLS challenges which are common to exploits.

Key Sections

SSL vs TLS

TLS (Transport Layer Security) is the successor to SSL (Secure Socket Layer) protocol for authentication and encryption. At present, TLS 1.3 is considered to be the most secure compared to it predecessors and is defined in RFC 8446. SSL & TLS ver 1.2 are deprecated due to vulnerabilities and attacks to these protocols such as ROBOT, LogJam, & WeakHD.

These attacks have exploited the way key exchanges happen between client and server during the negotiation phase. These attacks have been mitigated with the introduction of TLS 1.2, however there are still vulnerable to downgrade attacks such as POODLE. These vulnerabilities have been mitigated in TLS 1.3 which protects the handshake during client-server negotiation.

What attacks does SSL/TLS prevent?

SSL/TLS is the defacto standard in internet/online security. These protocols are used to encrypt data sent over the unsecured medium (the Internet) between a client machine and a server (a website hosted on a computer). This prevents many types of attacks. Even if a hacker intercepts encrypted data, he/she can’t read it or use it for beneficial purposes without the private key used for the decryption process.

SSL/TLS makes websites secure as it often protects data from being stolen, modified, or spoofed. No website can be 100% secure, but any website that stores customer’s personal information or other sensitive data should have SSL/TLS enabled to add a greater level of security that increases customer confidence.

The hackers in the world continuously search for ways to break the defacto standards of internet i.e. SSl/TLS. SSL/TLS vulnerability’s highly rewarding nature makes the attackers put their best efforts forward, which places organizations at risk of breaches and unplanned system downtime. The following examples of attacks describe a few of the most common SSL/TLS exploitation techniques, their impact on businesses, and suggestions on how to prevent these attacks.

Following are the common SSL attacks explained

SSL Renegotiation Attack

SSL Renegotiation attacks aim to exploit the vulnerability discovered in the SSL renegotiation procedure, which allows an attacker to inject plaintext into the victim’s requests. Attackers who can hijack an HTTPS connection can add their own requests to the conversation between the client and server. The attacker cannot decrypt the client-server communication, so it is different from a typical man-in-the-middle attack.

To fix the renegotiation vulnerability for SSLv3, you must stop allowing renegotiation on the server side. A renegotiation indication extension, which fixes the vulnerability, was proposed for TLS that requires the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

SSL/TLS Downgrade Attacks

An SSL/TLS downgrade attack tricks a web server into negotiating connections with previous versions of TLS that have long since been abandoned as insecure. The attacker then tries to intercept and/or alter the information by exploiting flaws in the older protocol versions or cryptographic algorithms.

Following are the most infamous Downgrade attacks in the history:

Poodle AttackIn the POODLE (Padding Oracle on Downgraded Legacy Encryption) attack, a vulnerability (CVE-2014-3566) is exploited to eavesdrop on communications encrypted with SSLv3.In this attack, the attacker can steal confidential data such as passwords, session cookies etc, to imitate a legitimate user. The recent Acunetix 2020 Web Application Vulnerability Report shows that as many as 3.9% of web servers are still vulnerable to POODLE as they are still using SSLv3 to encrypt their communication. To fix the POODLE attack on your web server, configure the web server to support TLS 1.2 or higher protocols.
Freak AttackThe FREAK (Factoring RSA Export Keys) attack works by exploiting the deliberately weak export cipher suites introduced to comply with US cryptography export regulation agencies. FREAK tricks the server into using an export cipher suite that uses RSA moduli of 512 bits or less. The earliest intention was to allow the cipher suites to be broken only by the National Security Agency however, this key can be easily cracked by today’s computing power. To fix this for your website, you must disable support for any export-grade cipher suites in software using SSL/TLS.
Logjam AttackThe Logjam attack, discovered in May 2015, allows an attacker to intercept an HTTPS connection by downgrading the connection to 512-bit, export-grade Diffie-Hellman groups. This is similar to the FREAK attack, except that Logjam attacks the Diffie-Hellmankey exchange instead of the RSA key exchange, as is the case in Freak attack. To overcome this, you must disable support for all export-grade Diffie-Hellman cipher suites on your servers. This won’t allow an attacker downgrade the connection to the 512-bit DH export key

Drown Attacks

DROWN is a serious vulnerability that targets servers supporting contemporary SSL/TLS protocol suites by exploiting their support for obsolete and insecure protocols. This allows attackers to leverage an attack on connections using up-to-date protocols that would otherwise be secure. DROWN exploits a vulnerability in the protocols and configuration of the server, rather than any specific implementation error.

DROWN gives attackers the ability to break the encryption, and read or steal sensitive communications. To protect against DROWN attack, server owners need to ensure that their private keys are not used anywhere with server software that allows SSLv2 connections. Web servers, SMTP servers, IMAP, and POP servers are all examples that supports SSLv2 connections.

Truncation attack

A TLS truncation attack blocks a victim’s account logout requests so that the user unknowingly remains logged into a web service. When the sign out request is sent, the attacker injects an unencrypted TCP FIN message to close the connection. The server does not receive the logout request, and is unaware of the abnormal termination. To prevent this, SSLv3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Sweet32 Attack

The Sweet32 attack breaks 64-bit block ciphers used in CBC mode by exploiting a “birthday attack”. In order to execute birthday attack, the attacker uses “man-in-the-middle” attacks or injects malicious JavaScript into a web page to capture enough traffic to mount a birthday attack. To protect against Sweet32 attack, avoid the usage of legacy 64-bit block ciphers, and disable cipher suites using DES/3DES.

MITM (Man in The Middle Attack)

Man in the middle (MITM) attacks occur when a hacker is able to get unauthorized access and intercept the secure communication between the sender and the receiver. There are many ways by which a hacker is able to perform MITM attacks, which include getting access to SSL/TLS private keys that bind the certificate authenticity and unsecured end points. In some case, poorly secured Intermediate Certificate Authority’s private keys can get compromised, leading to a much bigger impact on all the certificates issued by them.

In some cases, MITM attacks can also happen if the end point system is vulnerable and an attacker is able to add a fake trusted Root CA certificate in the trusted root authority list.Many organizations are not able to manage certificate life cycles, leading to compromised or expired certificates not getting revoked or renewed. In such a case, there is a high possibility that an attacker will continue using such revoked certificates to establish trust with a compromised.sites and be able to eavesdrop on communications on secured channels.

SSL Stripping attacks

In SSL Stripping, an attacker establishes theirself as a router and establishes HTTPS connections with Internet servers. Usually, the end-user connects with the attacker over the unsecured HTTPS connection believing it’s an authenticated router. The attacker is then able to read the communication, forward the request to the server, and pass the response back to the user. The intent of such attacks is to read data such as usernames, passwords, and any payment related data that the attacker can later exploit.

SSL Hijacking attacks

Session hijacking, also known as cookie hijacking, is the exploitation of a valid session by gaining unauthorized access to the session key/ID information. In the process, when the user tries to login to the web application, the server sets a temporary remote cookie in the client’s browser to authenticate the session. This enables the remote server to remember the client’s login status. In order to execute session hijacking, a hacker needs to know the client’s session ID information. This can be obtained in different ways, such as by tricking the user into clicking a malicious link that contains a prepared session ID.

Through both methods, the attacker can take over the targeted session by using the stolen session ID in their own browser session. Eventually, the server is tricked into thinking that the attacker’s connection is the same as the real user’s original session. To protect yourself against SSL hijacking, avoid connecting to non-secure (HTTP) urls, be careful while connecting to thepublic wi-fi, use secure cookie flag, use anti-malware on clients as well as server machines, and time-out inactive sessions.