Home » Articles » SSL Is Not a Badge Of Total Security
Click Here To Hide Tor

SSL Is Not a Badge Of Total Security

Although SSL is an encryption protocol (or a security measure in general) to cover up or protect active traffic between a user and a web server, it can’t prevent eavesdropping. In spite of SSL, advance hackers can sniff in on traffic, analyse active traffic, and monitor traffic to steal sensitive information via session hijacking and other forms of web attack.  Nevertheless, basic users still prefer to purchase items on sites with extended validation certificate certified by Symantec and other reputable ones.  Perhaps that green padlock on the left side of the unique resource locator/Indicator is quite enough to protect them from intruders.

Before I explain into details why SSL is not entirely secure but still needed just to boost “user’s confidence” and how attackers can employ diverse session hijacking methods and even Reflected File Download to make SSL redundant, let’s practically understand the mechanism of SSL.

First and foremost, SSL is far different from SSH. System administrators use SSH to securely access remote services via telnet. Typically Telnet  uses port 23. When traffic is encrypted with SSH, routing firewalls or natural routers, network access control and media access control recognise Telnet as port 22. The same can be said of FTP. FTP in its raw state uses port 20 and 21. FTP alongside SSH uses port22.

Like SSH, SSL encrypts traffic .However, both encryption protocols do not use the same logical port 22. SSL uses port 443 and 636 when encrypting HTTP and Lightweight Directory Access Protocol /SSL respectively. Instead of encrypting traffic with SSL, security researchers suggest or better recommend TLS over SSL. Although both encryption protocols offer encryption service, security experts prefers TLS/SSL.

SSL works at the application layer (in TCP/IP model). It provides secure communication between user agents and web servers. In this context, the user agent is the user’s browser (Opera Mini, Chrome or Firefox).  The user agent communicates with the web server via two common HTTP methods – GET and POST (technically known as verbs).


The main motive of SSL is to provide clients and servers with three main goals: privacy, integrity and authentication. Let’s check out a brief typical scenario to understand the three main goals of SSL.

Walter Brian of </scorpion> wants to buy comic books from Sylvester’s online bookstores. To complete the process, Brian will need to transmit sensitive information, such as his credit card number via POST method.  Brian wants to make sure the information he sends to Sylvester’s server cannot be altered (Integrity), cannot be viewed by sniffers and cannot be received by unauthorised web servers.


The main function of SSL is to ensure secure communication between a user agent and a server. It functions effectively at the application layer (Level 7). In cyberspace, there are diverse ways of initiating attacks against systems.  Attackers can avoid SSL via the following session hijacking techniques, such as Calculating ID session, Brute forcing ID or exploit Reflected File Download, and other forms of attack. Instead of focusing on how attackers initiate web attacks to gain control of a user’s browser – which makes ssl redundant, let’s explore how an attacker can use reflected file download attack to make SSL a ‘dumb’ encryption protocol. You can check out further details of RFD attack via this link – http://blog.spiderlabs.com/2014/10/reflected-file-download-the-white-paper.html

RFD is a web attack vector that allows attackers to gain control of a user’s browser. In a RFD web attack, users follow malicious link to a trusted domain like www.google.com or Bing.com. Basic users (and even intermediate users) perceive Google.com, Bing.com and the likes as trusted domains.

Once a user downloads a file (whether PDF or .exe file) uploaded on a web server by an attacker, mission is accomplished. The attacker gains control of a user’s brower entirely – no matter SSL or extensions or plug-ins installed on the browser to oppose cyber attacks.

Finally, let observe and analyze the sequence of RFD attack.

Sequence of RFD Attack 

First step: The user follows a malicious link to Google.com or Duckduck.com

Second step: The user download an executable file on a trusted domain. Let’s assume all security indicators, such as SSL certificate show that the .exe file is hosted on a trusted web server.

Third Step: The user runs the file which contains malicious shell commands to gain complete control over the computer.

RFD attack allows attackers to gain control over a user’s machine (not just a user agent).  Therefore the need of SSL, although it is technically recommended by cybersecurity experts, is not a total badge of security. RFD web attack flawlessly defeats SSL security measures.  Do you really think SSL is a reliable encryption protocol? Please share your views.


  1. Who writes this shit? I got to the third pharagraph and realized that the writer doesn’t know what he’s talking about.

    • Jordan Wood

      I don’t see why on earth he/she felt the need to clarify a distinction between SSL & SSH but otherwise the article is not inaccurate, right? I just glossed over it and may be missing something though.

  2. Totally agree with Sad Sam. The author is obviously completely confused and doesn’t understand the various concepts he’s blending into a pile of BS.

  3. This article is shitly written & the author is obviously confused about certain terms. The author doesn’t even specify the difference between SSL (which is generally not recommended anymore) and TLS (what websites actually use in 2016, or at least should be.)

    Research elsewhere.

  4. The author tried too many drugs before writing this article. Or maybe I have tried too many drugs before reading it but the result is the same.

Leave a Reply

Your email address will not be published. Required fields are marked *


Captcha: *