SSL stripping: Basics and protection options

The Secure Sockets Layer (SSL) transfer protocol and its successor, Transport Layer Security (TLS), are amongst the most important building blocks for a secure web presence. They encrypt the information exchanged between browser and server via HTTP, before the information is sent – even when switching between an encrypted HTTPS and an unprotected page. This does not just prevent standard data transfer in plaintext, but also prevents a cookie set under SSL from being sent with an unencrypted connection. These useful SSL and TLS certificates also guarantee the authenticity of the server hostname to the requesting client. The TLS protocol provides security in numerous ways, which makes it indispensable whenever sensitive information is being transmitted.

TLS is generally one of the safest protocols, and has so far dealt well with attack attempts. However, under certain circumstances, special tools (such as the sslstrip programmed for demonstration purposes) are able to gain access to the data transfer before the encryption has begun. This type of unauthorized, third-party access is referred to as SSL stripping.

As early as 2002, the developer Moxie Marlinspike used sslsniff to program a tool that could eliminate SSL encryption. The proxy software made it possible to infiltrate SSL data streams and to exchange the server certificate with any of its own certificates. Marlinspike wanted to use the application to show the weaknesses of Internet Explorer, which was vulnerable to man-in-the-middle attacks at the time of publication.

Microsoft was able to secure the vulnerability, and other popular clients are widely protected from this kind of attack, provided they have the most up to date version and the correct configuration.

Marlinspike presented the sslstrip program in 2009 as part of the security conference Black Hat DC. Like his previous tool, sslstrip is a proxy that is positioned between client and server and tries to bypass certification on browser pages. To that end, the tool searches the web pages delivered by web servers for embedded links and referrals, which he redirects an SSL-protected log-in page, such as the following link:

If the proxy finds this kind of link, it modifies it to an equivalent HTTP link. The user sends the registration through his browser, rather than the supposedly encrypted ordinary data in the plaintext. A potential hacker can easily read through sslstrip as an intermediate station and reach confidential information. Since the SSL stripping does not create an invalid connection, no warning messages are displayed. Generally, the user does not receive a warning that the information he is transmitting is unencrypted.

Regardless of whether sslstrip or another similarly programmed application is used, the first thing an attacker does is switch the proxy between the browser and the web server. The software also has the ability to encode modified URLs by SSL stripping, but only if it can intercept or forward data flows. The following three methods are common in the implementation:

1. Incorrect entry of the proxy in the browser options: When your system is targeted, the goal is often just the browser, rather than the whole computer. Malware then ensures that an external proxy server is automatically entered in the settings without the user being aware.
2. ARP or NDP Spoofing: Within a subnet, an attacker can fall back on ARP spoofing (IPv4) or NDP-Spoofing (IPv6) to bring their proxy into play. The purpose of both protocols is to resolve the IP addresses into corresponding hardware addresses (also known as MAC addresses). Using manipulated messages from these protocols, the attacker can replace requested hardware addresses with his own system address, and then intercept the transmitted data packets.
3. Providing your own hotspot: The third option is that the device that the server proxy runs on can also act as a router. As a standard gateway, including a DHCP server, it can assign IP addresses to users, and read and forward packets that are sent beyond the boundaries of the subnet. This provides the perfect basis for SSL stripping.

After he has positioned the proxy, the attacker does not have to do much more for the SSL strip: he runs the tool, which sends out altered links when needed. If successful, is also sends out unencrypted information such as bank- or user log-in data.

Servers and browsers have no way of detecting an SSL strip. Both applications assume that they are communicating with the real contacted partner, which is why they do not doubt the integrity of the transmitted data. The situation is quite similar for users, because at first glance, visiting the website seems to go as normal.  SSL stripping can only be seen in a few exceptional cases, through technical or design details. Unless a strikingly faulty layout is presented, or considerable delays occur when loading the page, there are very few signs that SSL encryption is missing.

However, for quite a while now browser address lines have been providing hints in different ways: In order to identify websites with secure connections, the address bar was completely green in older versions of Microsoft Internet Explorer. Other browsers just highlighted the company’s previous name, until this type of identification – commonplace with the first web-enabled mobile devices – was replaced by today’s common symbols, such as the typical security lock. However, these visual hints do not always guarantee that the site being visited has not been compromised by tools like sslstrip. Since an attacker controls the whole data transfer, he is able to deliver a similar symbol to the favicon to perfect his deception.

The difficulty of detecting malicious pages makes SSL stripping attacks so dangerous to users: the encryption certificates which should be used by every careful website operator signify security and trustworthiness, and they do not give the visitors concerns about disclosing confidential information. In principle, SSL provides the necessary protection, since the ability to read and intercept data packets does not result from a security gap in the protocol, but from the fact that the encryption itself is prevented. To protect against SSL strips, each user should force the construction of encrypted HTTPS connections. Ways of doing this can be seen in the following examples:

1. Enter the URL manually: A cumbersome, but effective measure is entering the HTTPS URL into the browser
2. Browser Extension: There are several browser extensions that can help you access encrypted versions, if they exist. For example, the HTTPS Everywhere extension uses domain and rule lists to handle any page calls through HTTPS connections. Versions for Firefox, Android, Chrome, and Opera can be found on the Electronic Frontier Foundation website, which develops and supports the expansion together with the Tor project
3. Save secure URL’s as bookmarks: If you usually use an SSL protected web service (online banking, cloud storage etc.), you can save the HTTPS version as a bookmark and always access it that way. The condition for this is that you are in a secure network when you create the bookmark, otherwise you may add an already-manipulated URL to the Favorites list

You can also combat SSL stripping as the operator of a web project. For example, a basic step can be to enable encryption for all current pages and force incoming HTTP connections to secure their pages. The same thing applies to cookies: If you do not want to use practical data records for web analysis, make sure they are not sent back through unsecured HTTP connections. To do this, just record the cookies with the ‘secure’ attribute, ensuring that your server is only receiving feedback via HTTPS. A further safety measure is the IETF standard HSTS, which is described in more detail in the following section.

Three years after Marlinspike pointed out the vulnerability of SSL certified websites using his sslstrip software, the IETF (Internet Engineering Task Force) specified the security mechanism HSTS (http Strict Transport Security) in RFC 6797. This allows web servers to alert connection-building clients that they are accessing the website exclusively through a HTTPS connection for a specific amount of time. To this end, the server uses the ‘Strict Transport Security’ field in an ordinary HTTP response header, plus the ‘max age’ directive, which defines the validity period of the statement in seconds. To secure a domain and make it reachable only by encrypted connection for one year, the web server’s http response must contain something like the following line:

The ‘includeSubDomains’ parameter can be used to extend the command to all subdomains of the website, so that the use of SSL/TLS is enforced. If a browser receives a message from a contracted web server with a ‘Strict Transport Security’ statement, all unencrypted requests are automatically converted to encrypted in future connections to the relevant domains. If the connection is not secure, an error message is displayed and the requested page is not called.

HSTS is a permanent solution to protect a website and potential visitors from SSL strips and similar attacks. However, as previously mentioned, there is always a very first connection structure which can be manipulated before the safety mechanism can intervene. To counter this problem, Google has introduced a preload list for its Chrome browser, containing web projects only available via HTTPS. Other browser vendors have adopted the principle and implemented HSTS preload lists based on the Chrome list. To add your website to the list, you can submit a request to the project page set up by Google.