SSL Stripping

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 in­for­ma­tion exchanged between browser and server via HTTP, before the in­for­ma­tion is sent – even when switching between an encrypted HTTPS and an un­pro­tect­ed page. This does not just prevent standard data transfer in plaintext, but also prevents a cookie set under SSL from being sent with an un­en­crypt­ed con­nec­tion. These useful SSL and TLS cer­tifi­cates also guarantee the au­then­tic­i­ty of the server hostname to the re­quest­ing client. The TLS protocol provides security in numerous ways, which makes it in­dis­pens­able whenever sensitive in­for­ma­tion is being trans­mit­ted.

TLS is generally one of the safest protocols, and has so far dealt well with attack attempts. However, under certain cir­cum­stances, special tools (such as the sslstrip pro­grammed for demon­stra­tion purposes) are able to gain access to the data transfer before the en­cryp­tion has begun. This type of unau­tho­rized, third-party access is referred to as SSL stripping.

As early as 2002, the developer Moxie Mar­lin­spike used sslsniff to program a tool that could eliminate SSL en­cryp­tion. The proxy software made it possible to in­fil­trate SSL data streams and to exchange the server cer­tifi­cate with any of its own cer­tifi­cates. Mar­lin­spike wanted to use the ap­pli­ca­tion to show the weak­ness­es of Internet Explorer, which was vul­ner­a­ble to man-in-the-middle attacks at the time of pub­li­ca­tion. Microsoft was able to secure the vul­ner­a­bil­i­ty, and other popular clients are widely protected from this kind of attack, provided they have the most up to date version and the correct con­fig­u­ra­tion. Mar­lin­spike presented the sslstrip program in 2009 as part of the security con­fer­ence Black Hat DC. Like his previous tool, sslstrip is a proxy that is po­si­tioned between client and server and tries to bypass cer­ti­fi­ca­tion 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 equiv­a­lent HTTP link. The user sends the reg­is­tra­tion through his browser, rather than the sup­pos­ed­ly encrypted ordinary data in the plaintext. A potential hacker can easily read through sslstrip as an in­ter­me­di­ate station and reach con­fi­den­tial in­for­ma­tion. Since the SSL stripping does not create an invalid con­nec­tion, no warning messages are displayed. Generally, the user does not receive a warning that the in­for­ma­tion he is trans­mit­ting is un­en­crypt­ed.

Re­gard­less of whether sslstrip or another similarly pro­grammed ap­pli­ca­tion 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 im­ple­men­ta­tion:

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 au­to­mat­i­cal­ly 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 cor­re­spond­ing hardware addresses (also known as MAC addresses). Using ma­nip­u­lat­ed messages from these protocols, the attacker can replace requested hardware addresses with his own system address, and then intercept the trans­mit­ted 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 bound­aries of the subnet. This provides the perfect basis for SSL stripping.

After he has po­si­tioned 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 suc­cess­ful, is also sends out un­en­crypt­ed in­for­ma­tion such as bank- or user log-in data.

Servers and browsers have no way of detecting an SSL strip. Both ap­pli­ca­tions assume that they are com­mu­ni­cat­ing with the real contacted partner, which is why they do not doubt the integrity of the trans­mit­ted 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 ex­cep­tion­al cases, through technical or design details. Unless a strik­ing­ly faulty layout is presented, or con­sid­er­able delays occur when loading the page, there are very few signs that SSL en­cryp­tion 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 con­nec­tions, the address bar was com­plete­ly green in older versions of Microsoft Internet Explorer. Other browsers just high­light­ed the company’s previous name, until this type of iden­ti­fi­ca­tion – com­mon­place 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 com­pro­mised 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 dif­fi­cul­ty of detecting malicious pages makes SSL stripping attacks so dangerous to users: the en­cryp­tion cer­tifi­cates which should be used by every careful website operator signify security and trust­wor­thi­ness, and they do not give the visitors concerns about dis­clos­ing con­fi­den­tial in­for­ma­tion. In principle, SSL provides the necessary pro­tec­tion, 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 en­cryp­tion itself is prevented. To protect against SSL strips, each user should force the con­struc­tion of encrypted HTTPS con­nec­tions. Ways of doing this can be seen in the following examples:

1. Enter the URL manually: A cum­ber­some, but effective measure is entering the HTTPS URL into the browser
2. Browser Extension: There are several browser ex­ten­sions that can help you access encrypted versions, if they exist. For example, the HTTPS Every­where extension uses domain and rule lists to handle any page calls through HTTPS con­nec­tions. Versions for Firefox, Android, Chrome, and Opera can be found on the Elec­tron­ic Frontier Foun­da­tion 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-ma­nip­u­lat­ed 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 en­cryp­tion for all current pages and force incoming HTTP con­nec­tions 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 con­nec­tions. 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 Mar­lin­spike pointed out the vul­ner­a­bil­i­ty of SSL certified websites using his sslstrip software, the IETF (Internet En­gi­neer­ing Task Force) specified the security mechanism HSTS (http Strict Transport Security) in RFC 6797. This allows web servers to alert con­nec­tion-building clients that they are accessing the website ex­clu­sive­ly through a HTTPS con­nec­tion 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 con­nec­tion for one year, the web server’s http response must contain something like the following line:

The ‘in­cludeSub­Do­mains’ parameter can be used to extend the command to all sub­do­mains of the website, so that the use of SSL/TLS is enforced. If a browser receives a message from a con­tract­ed web server with a ‘Strict Transport Security’ statement, all un­en­crypt­ed requests are au­to­mat­i­cal­ly converted to encrypted in future con­nec­tions to the relevant domains. If the con­nec­tion 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 pre­vi­ous­ly mentioned, there is always a very first con­nec­tion structure which can be ma­nip­u­lat­ed before the safety mechanism can intervene. To counter this problem, Google has in­tro­duced a preload list for its Chrome browser, con­tain­ing web projects only available via HTTPS. Other browser vendors have adopted the principle and im­ple­ment­ed 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.