Performing & Preventing SSL Stripping: A Plain-English Primer
October 20, 2017 4:23 PM
Over the past few days we learned about a new attack that posed a serious weakness in the encryption protocol used to secure all modern Wi-Fi networks....
\n \n \n
The internet is built on a patchwork of standards, with components being refactored and rebuilt in new published standards. When one standard is found to be flawed, it is later patched or replaced by a new standard. As a standard is falsified and replaced by a better one, the internet as a whole becomes better.
The HTTP protocol was originally specified to communicate data in the clear over the internet. Prior to the official introduction of HTTP 1.0, the first documented version of HTTP was known as HTTP V0.9 and was published in 1991. Netscape were the first to recognise the need for greater security assurance over the internet and in mid-1994 HTTPS was implemented into the Netscape browser. In order to implement greater security assurance, a technology called SSL (Secure Socket Layer) was created.
SSL 1.0 was short-lived (and not even officially standardised) due to a number of security concerns and shortcomings. This protocol was incrementally updated in SSL 2.0 and SSL 3.0; this was then iteratively superseded by the TLS (Transport Layer Security) standards.
Protocol | SSL 1.0 | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
Release | N/A | 1995 | 1996 | 1999 | 2006 | 2008 | Draft |
Each of those versions come with different security constraints and support varies from browser-to-browser. Additionally, the encryption ciphers used can be configured somewhat independently of the overlying protocol. It is therefore vital to ensure any HTTPS-enabled web server is set up to use a configuration that’s optimised to balance browser support against security. I won't go into detail on this in this post, however you can read about SSL and TLS Deployment Best Practices in documentation provided by SSL Labs.
At a high-level; the end result of HTTP over TLS, is that when a site is requested over https://
instead of http://
the connection is completed in an encrypted manner. 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. When a secure connection is established, web browsers can indicate this to their users by lighting the browser bar green.
As SSL Certificates themselves are signed by Certificate Authorities, a degree of "domain validation" is carried out - the Certificate Authority makes sure they are only validating a certificate which is owned by someone who has the ability to make changes to the website. This provides a degree of assurance that certificates aren't being issued to attackers who can then seem legitimate when intercepting web traffic. In the event a certificate ends up in the wrong hands, a Certificate Revocation List can be used to retract the certificate. Such lists are then automatically downloaded by modern Operating Systems to ensure that when an invalid certificate is served, it is marked as insecure in the browser. As there are a considerable number (>100) certificate authorities with the power to issue SSL certificates, it is possible to allowlist which Certificate Authorities should issue certificates for a given domain by configuring CAA DNS records.
\nNowadays, this process can be simplified, for example; when your traffic is proxied through the Cloudflare network, we will dynamically manage renewing and signing your certificate for you (whilst using Cloudflare's Origin CA to generate a certificate to encrypt traffic back to the origin web server). Similarly, the EFF offer a tool called CertBot to make it relatively easy to install and generate Let's Encrypt certificates from the command line.
When using HTTPS, it is important that the entire content of the website is then loaded over HTTPS - not just the login pages. It used to be common practice for websites to initially present the login page over a secure encrypted connection, then when the user was logged in, they would degrade the connection back to HTTP. Once logged into a website, a session cookie is stored on the local browser to allow the website to ensure the user is logged in.
In 2010, Eric Butler demonstrated how insecure this was by building a simple interception tool called FireSheep. By Eavesdropping wireless connections, FireSheep would capture the login session for common websites. Whilst the attacker would not necessarily be able to capture the password of the website, they would be able to capture the login session and perform behaviours on websites as if they were login. They would also be able to intercept traffic as the user was logged in.
When connecting to a website using SSL, the first request should usually redirect the user to a secure version of the website. For example; when you first visit http://www.cloudflare.com/
a HTTP 301 redirect is used to send you to the HTTPS version of the site, https://www.cloudflare.com/
.
This raises an important question; if someone is able to intercept the unencrypted request to the HTTP version of the site, couldn't they then strip away the encryption and serve the site back to the user without encryption? This was a question explored by Moxie Marlinspike, which later led to the creation of HSTS.
\nIn 2009 at Blackhat DC, Moxie Marlinspike presented a tool known as SSLStrip. This tool would intercept HTTP traffic and whenever it spotted redirects or links to sites using HTTPS, it would transparently strip them away.
Instead of the victim connecting directly to a website; the victim would connect to the attacker, and the attacker would initiate the connection back to the website. This attack is known as an on-path attack.
The magic of SSLStrip was that whenever it would spot a link to a HTTPS webpage on an unencrypted HTTP connection, it would replace the HTTPS with a HTTP and sit in the middle to intercept the connection. The interceptor would make the encrypted connection to back to the web server in HTTPS, and serve the traffic back to the site visitor unencrypted (logging any interesting passwords or credit card information in the process).
In response, a protocol called HTTP Strict Transport Security (HSTS) was created in 2012 and specified in RFC 6797. The protocol works by the server responding with a special header called Strict-Transport-Security
which contains a response telling the client that whenever they reconnect to the site, they must use HTTPS. This response contains a "max-age"
field which defines how long this rule should last for since it was last seen.
Whilst this provided an improvement in preventing interception attacks, it wasn't perfect and there remain a number of shortcomings.
\nOne of the shortcomings of HSTS is the fact that it requires a previous connection to know to always connect securely to a particular site. When the visitor first connects to the website, they won't have received the HSTS rule that tells them to always use HTTPS. Only on subsequent connections will the visitor's browser be aware of the HSTS rule that requires them to connect over HTTPS.
Other mechanisms of attacking HSTS have been explored; for example by hijacking the protocol used to the sync a computer's time (NTP), it can be possible to set a computers date and time to one in the future. This date and time can be set to a value when the HSTS rule has expired and thereby bypassing HSTS[2].
HSTS Preload Lists are one potential solution to help with these issues, they effectively work by hard coding a list of websites that need to be connected to using HTTPS-only. Sites with HSTS enabled can be submitted to the Chrome HSTS Preload List at hstspreload.org; which is also used as the basis of the preload lists used in other browsers.
Inside the source code of Google Chrome, there is a file which contains a hard-coded file listing the HSTS properties for all domains in the Preload List. Each entry is formatted in JSON and looks something like this:
\nEven with preload, things still aren't perfect. Suppose someone is reading a blog about books and on that blog there is a link to purchase a book from an online retailer. Despite the fact the online retailer enforces HTTPS using HSTS it is possible to conduct an on-path attack, providing the blog linking to the online retailer does not use HTTPS.
\nLeonardo Nve revived SSLStrip in a new version called SSLStrip+, with the ability to avoid HSTS. When a site is connected to over an unencrypted HTTP connection, SSLStrip+ will look for links to HTTPS sites. When a link is found to a HTTPS site, it is rewritten to HTTP and critically the domain is rewritten to an artificial domain which is not on the HSTS Preload list.
For example; suppose a site contains a link to https://example.com/
, the HSTS could be stripped by rewriting the URLs to http://example.org/
; with attacker sitting in the middle, receiving traffic from http://example.org/
and proxying it to https://example.com/
.
Such an attack can also be performed against redirects; suppose http://example.net/
is loaded over HTTP but then redirects to https://example.com/
which is loaded over HTTPS. At the point the redirect is carried out, the legitimate HSTS-protected site can be redirected to a phony domain which the attacker uses to serve traffic over HTTP and intercept traffic.
As more and more of the internet moves to HTTPS, the surface area of this attack will get smaller as there is less unencrypted HTTP traffic to intercept.
In the latest newly-released version of Google Chrome (version 62), websites which serve input forms (such as credit card forms and password fields) on insecure connections are flagged as "Not Secure" to the user, instead of a neutral message. When in Incognito (private browsing) mode, Chrome will flag any website as insecure if it does not use HTTPS.
\nThis change helps make it clearer to users when HTTPS has been stripped away from a webpage as they try to log in. Additionally, in making this change, it hoped that more websites will adopt HTTPS - thereby improving the security of the internet as a whole.
\nThis blog post has discussed mechanisms of stripping HTTPS away from websites and in particular how HSTS can affect this. It is worth noting that there are other potential attack vectors within various HTTPS specifications and in certain ciphers; this blog post hasn't gone into them.
Despite HTTPS offering a mechanism for encrypting web traffic, it is important to implement technologies such as HTTP Strict Transport Security to ensure it is enforced, and preferably submit your site to HSTS Preload lists. As more websites do this, the security of the internet overall is improved.
To learn how you can implement HTTPS and HSTS in practice, I'd highly recommend Troy Hunt's blog post: The 6-Step "Happy Path" to HTTPS. His blog post goes into how you can enable strong HTTPS in practice, and additionally touches on a technology that I didn't mention here known as CSP (Content Security Policy). CSP allows you to automatically upgrade or block HTTP requests when loading pages over HTTPS, as this poses another attack vector.
Stubblefield, A., Ioannidis, J. and Rubin, A.D., 2002, February. Using the Fluhrer, Mantin, and Shamir Attack to Break WEP. In NDSS. ↩︎
Selvi, J., 2014. Bypassing HTTP strict transport security. Black Hat Europe. ↩︎
October 20, 2017 4:23 PM
Over the past few days we learned about a new attack that posed a serious weakness in the encryption protocol used to secure all modern Wi-Fi networks....
September 26, 2017 1:00 PM
Today we announced Geo Key Manager, a feature that gives customers control over where their private keys are stored with Cloudflare. This builds on a previous Cloudflare innovation called Keyless SSL and a novel cryptographic access control mechanism....
September 12, 2017 4:29 PM
This post summarizes how prevalent encrypted web traffic interception is and how it negatively affects online security according to a study published at NDSS 2017 authored by several researchers including the author of this post and Nick Sullivan of Cloudflare. ...
September 01, 2017 8:48 PM
Most of today's cryptography is designed to be secure against an adversary with enormous amounts of computational power. This means estimating how much work certain computations require, and choosing cryptographic parameters based on our best estimates....
July 10, 2017 12:43 PM
At Cloudflare our focus is making the internet faster and more secure. Today we are announcing a new enhancement to our HTTPS service: High-Reliability OCSP stapling....
March 15, 2017 2:00 PM
Cloudflare’s mission is to help build a faster and more secure Internet. Over the last several years, the Internet Engineering Task Force (IETF) has been working on a new version of TLS, the protocol that powers the secure web....
February 07, 2017 7:31 PM
Come join us on Cloudflare HQ in San Francisco on Tuesday, Febrary 28, 2017 for another cryptography meetup. We again had a great time at the last one, we decided to host another. It's becoming a pattern....
February 01, 2017 2:57 PM
Nick Sullivan and I gave a talk about TLS 1.3 at 33c3, the latest Chaos Communication Congress. The congress, attended by more that 13,000 hackers in Hamburg, has been one of the hallmark events of the security community for more than 30 years....
December 26, 2016 2:59 PM
Back when crypto/tls was slow and net/http young, the general wisdom was to always put Go servers behind a reverse proxy like NGINX. That's not necessary anymore!...
November 02, 2016 11:45 PM
Come join us on Cloudflare HQ in San Francisco on Tuesday, November 22 for another cryptography meetup. We had such a great time at the last one, we decided to host another....
October 12, 2016 3:05 PM
One of the base principles of cryptography is that you can't just encrypt multiple messages with the same key. At the very least, what will happen is that two messages that have identical plaintext will also have identical ciphertext, which is a dangerous leak. ...
September 23, 2016 4:01 PM
The CloudFlare London office hosts weekly internal Tech Talks (with free lunch picked by the speaker). My recent one was an explanation of the latest version of TLS, 1.3, how it works and why it's faster and safer....
May 10, 2016 3:21 PM
At CloudFlare we strive to combine features that are simple, secure, and backed by solid technology. The Origin CA is a great example of this. You no longer need to go to a third-party certificate authority to protect the connection between CloudFlare and your origin server....
April 08, 2016 1:40 PM
Now back in HD: the CloudFlare Cryptography Meetup series. A while back, CloudFlare hosted a pair of Meetups focused on encryption and cryptographic technology. ...
February 12, 2016 2:00 PM
At CloudFlare, we’re committed to making sure the encrypted web is available to everyone, even those with older browsers. At the same time, we want to make sure that as many people as possible are using the most modern and secure encryption available to them. ...
December 25, 2015 8:49 AM
It’s December 25th, which means most of you are probably at home visiting with family. I asked a few of the security engineers here at CloudFlare how they explain their jobs when they’re home for the holidays, and here's what they had to say....
May 07, 2015 10:06 AM
It is no secret that we at CloudFlare love Go. We use it, and we use it a LOT. There are many things to love about Go, but what I personally find appealing is the ability to write assembly code!...
February 23, 2015 8:22 PM
CloudFlare is always trying to improve customer experience by adopting the latest and best web technologies so that our customers (and their visitors) have a fast and a secure web browsing experience....
October 01, 2014 10:57 PM
On Monday, we announced Universal SSL, enabling HTTPS for all websites using CloudFlare’s Free plan. Universal SSL represents a massive increase in the number of sites we serve over HTTPS—from tens of thousands, to millions....