Note: This is the first of a two-part blog series. This post discusses the threat of SSL stripping attacks while the second post tries to examine whether the implementation of HTTPS on a site-wide scale is the answer to this threat.
The KRACK Attack effectively demonstrated that corporate users can’t blindly trust the medium that connects them to the internet. It also illustrates how encryption can be completely stripped away even if the site supports HTTPS.
Stripping away the encryption offered by HTTPS, called SSL Strip, is a serious cyber threat to many corporations since their employees are constantly on the move and require access to Internet on-the-go even through open non-secure Wi-Fi hotspots. Once attackers gain access to a network, they can act as a Man-in-the-Middle (MITM) to intercept connections over the network. These interception tactics can also be deployed against wired networks, provided that someone gains access to an Ethernet port.
The creator of SSL strip vulnerability is Moxie Marlinspike, a well-known American computer security researcher. In 2009, he spoke about this dangerous SSL weakness for the first time at the Black Hat information security event. According to Marlinspike’s presentation, the exploitation of this vulnerability is very serious threat for the privacy of our digital credentials since it can happen in real time, undetected, and targets whatever secure sites people are browsing to at any moment. It doesn't require multiple certificates and once the attacker gets his “dirty work” done, he can switch the victims back to a normal traffic stream.
HTTP and HTTPS are the application-layer protocols in a TCP/IP model, as illustrated in the figure below. HTTPS uses a secure tunnel to transfer and receive data which is commonly called SSL/TLS (Secure Socket Layer / Transport Layer Security), and therefore the suffix ‘S’ is added to HTTPS.
SSL/TLS is a secure protocol used to communicate sensitive information. This protocol is used when exchanging sensitive data such as banking information and email correspondence for example. The protocol’s security is established by creating an encrypted connection between two parties (usually a client application and a server). Browsers and web servers regularly use this protocol when a secure connection is needed. In most scenarios the following events take place when establishing a secure connection:
This process provides a reasonable guarantee of both privacy and integrity. In other words, we don't just encrypt the messages we're sending, we make sure the message we receive isn't altered over the wire.
In order to “strip” the SSL, an attacker intervenes in the redirection of the HTTP to the secure HTTPS protocol and intercepts a request from the user to the server. The attacker will then continue to establish an HTTPS connection between himself and the server, and an unsecured HTTP connection with the user, acting as a “bridge” between them.
How can the SSL Strip trick both the browser and the website’s server? The SSL Strip takes advantage of the way most users come to SSL websites. The majority of visitors connect to a website’s page that redirects through a 302 redirect, or they arrive on an SSL page via a link from a non-SSL site. If the victim wants, for instance, to buy a product and types the URL www.buyme.com in the address bar, the browser connects to the attacker machine and waits for a response from the server. In an SSL Strip, the attacker, in turn, forwards the victim’s request to the online shop’s server and receives the secure HTTPS payment page. For example: https://www.buyme.com. At this point, the attacker has complete control over the secure payment page. He downgrades it from HTTPS to HTTP and sends it back to the victim’s browser. The browser is now redirected to http://www.buyme.com. From now onward, all the victim’s data will be transferred in plain text format, and the attacker will be able to intercept it. Meanwhile, the website’s server will think that it has successfully established the secure connection, which indeed it has—but with the attacker’s machine, not the victim’s.
SSL Strip attacks can be implemented in a number of ways. The most common method is by creating a hotspot and allowing the victims to connect to it. Many attackers establish fake hotspots with names similar to legitimate hotspot names, for example, “Starbucks Coffee” instead of “Starbucks”. Unaware, the user connects to the malicious hotspot. Once the user tries to connect to the server, the attacker uses his control over the hotspot and attacks the user.
After the successful implementation of an SSL strip attack, the victim’s information is transferred in plain text format and can be easily intercepted by anyone, including the attacker. This results in a breach in the integrity and confidentiality of personal identifiable information (PII) such as login credentials, bank accounts, sensitive business data, etc. Hence the threat of this vulnerability is easily understood and may have varying implications to your digital presence. Your business relies on encrypted communications to transact securely across the edge to the endpoint. But what if you can’t trust the identifying certificates on each end of the channel? Without this trust, you can’t engage in e-commerce web transactions and online banking that your consumers now rely on without having a second thought about security.<
The question to be answered now is this: what can we do to secure ourselves against this threat? Is the adoption of HTTPS and the Chrome updates a panacea?