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).
THREE MAIN GOALS OF SSL
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.
WHY SSL IS NOT A BADGE OF TOTAL SECURITY
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.