Only 1 in 20 HTTPS servers correctly implements HTTP Strict Transport Security, a widely-supported security feature that prevents visitors making unencrypted HTTP connections to a server.
The remaining 95% are therefore vulnerable to trivial
connection hijacking attacks, which can be exploited to carry out effective phishing,
pharming and man-in-the-middle attacks. An attacker can exploit these vulnerabilities whenever a user inadvertently tries to access a secure site via HTTP, and so the attacker does not even need to spoof
a valid TLS certificate. Because no crypto-wizardry is required to hijack an HTTP connection,
these attacks are far easier to carry out than those that target TLS, such as the recently announced
The growth of HTTPS has been a mostly positive step in the evolution of the
internet, enabling encrypted communications between more users and websites than
ever before. Many high profile sites now use HTTPS by default, and millions of TLS
certificates are currently in
use on the web. With companies like Let’s Encrypt offering free certificates and
automated management tools, it is also easier than ever to deploy an HTTPS
website that will be trusted by all modern browsers.
The primary purpose of a TLS certificate is to allow a browser to verify that
it is communicating with the correct website. For example, if
https://www.example.com uses a valid TLS
certificate, then a man-in-the-middle attacker would not be able to hijack a
browser’s connection to this site unless he is also able to obtain a valid
certificate for that domain.
It would be extremely difficult for the attacker
to obtain a valid certificate for a domain he does not control, and using an
invalid certificate would cause the victim’s browser to display an appropriate
warning message. Consequently, man-in-the-middle attacks against HTTPS services
are hard to pull off, and often not very successful. However, there are plenty of realistic
opportunities to use the unencrypted HTTP protocol to attack most HTTPS
HTTP Strict Transport Security (HSTS)
Encrypted communications are an essential requirement for banks and other
financial websites, but HTTPS alone is not sufficient to defend these sites
against man-in-the-middle attacks. Astonishingly, many banking websites lurk amongst the 95% of HTTPS
servers that lack a simple feature that renders them
still vulnerable to pharming and man-in-the-middle attacks.
This missing feature is HTTP Strict Transport Security (HSTS), and
only 1 in 20 secure servers currently make use of it, even though it is
supported by practically all modern browsers.
Each secure website that does not implement an HSTS policy can be attacked simply by
hijacking an HTTP connection that is destined for it. This is a surprisingly feasible attack vector, as there are many ways in which a user can inadvertently end up connecting via HTTP instead of HTTPS.
Manually typed URLs often result in an initial insecure request, as most users do not explicitly type in the protocol string (http:// or https://). When no protocol is given, the browser will default to HTTP – unless there is an appropriate HSTS policy in force.
To improve accessibility, most secure websites also run an
HTTP service to redirect users to the corresponding HTTPS site – but this makes them particularly prone to man-in-the-middle attacks if there is no HSTS policy in force.
Not only would many users be accustomed to visiting the HTTP site first, but anyone else who visits the site via an old bookmark or search engine result might also initially access the site via an insecure HTTP address. Whenever this happens, the attacker can hijack the initial HTTP request and prevent
the customer being redirected to the secure HTTPS website.
This type of attack can be automated with the sslstrip tool, which transparently hijacks HTTP traffic on a network and converts HTTPS links and redirects into HTTP. This type of exploit is sometimes regarded as a protocol downgrade attack, but strictly speaking, it is not: rather than downgrading the protocol, it simply prevents the HTTP protocol being upgraded to HTTPS.
Vulnerable sites can be attacked on a massive scale by compromising home routers or DNS
servers to point the target hostname at a server that is controlled by the
attacker (a so-called “pharming” attack). Some smaller scale attacks can be carried out very easily –
for example, if an attacker sets up a rogue Wi-Fi access point to provide internet access to nearby victims, he can easily influence the results of their DNS lookups.
Even if a secure website uses HTTPS
exclusively (i.e. with no HTTP service at all), then man-in-the-middle attacks
are still possible. For example, if a victim manually types www.examplebank.com
into his browser’s address bar—without prefixing it with https://—the
browser will attempt to make an unencrypted HTTP connection to
http://www.examplebank.com, even if the
genuine site does not run an HTTP service. If this hostname has been
pharmed, or is otherwise subjected to a man-in-the-middle attack, the attacker
can hijack the request nonetheless and eavesdrop the connection as it is relayed
to the genuine secure site, or serve phishing content directly to the victim.
In short, failing to implement an HSTS policy on a secure website means
attackers can carry out man-in-the-middle attacks without having to obtain a
valid TLS certificate. Many victims would fall for these attacks, as they can be
executed over an unencrypted HTTP connection, thus avoiding any of the browser’s
tell-tale warnings about invalid certificates.
Implementing HSTS: A simple one-liner
The trivial man-in-the-middle attacks described above can be thwarted by
implementing an appropriate HSTS policy. A secure website can do this simply by
setting a single HTTP header in its responses:
This header can only be set over an HTTPS connection, and instructs
compatible browsers to only access the site over HTTPS for the next year
(31,536,000 seconds = 1 year). This is the most common
max-age value, used by
nearly half of all HTTPS servers.
After this HSTS policy has been applied, even if a user manually prefixes the site’s
hostname with http://, the browser will ignore this and access the site over
The combination of HSTS and HTTPS therefore provides a good defence against
pharming attacks, as the attacker will not be able to redirect and intercept plaintext HTTP
traffic when a client obeys the HSTS policy, nor will he be able to
present a valid TLS certificate for the site he is impersonating.
The attacker cannot even rely on a small proportion his victims unwisely ignoring the use of an invalid certificate, as browsers must regard this situation as a hard fail when an HSTS policy is in force. The browser will simply not let the victim access the site if it finds an invalid certificate, nor will it allow an exception to be added.
To prevent other types of attack, it is also wise to add the
includeSubDomains directive to ensure that every possible subdomain of a site is
protected by HSTS. This mitigates cookie injection and session fixation attacks
that could be executed by impersonating an HTTP site on a non-existent subdomain
such as foo.www.example.com, and using it to set a cookie which would be sent to
the secure site at https://www.example.com.
This directive can be enabled like so:
Strict-Transport-Security: max-age=31536000; includeSubDomains
However, some thought is required before taking the carte blanche approach of
including all subdomains in an HSTS policy. The website’s administrators must
ensure that every single one of its subdomains supports HTTPS for at least the
duration specified by the
max-age parameter, otherwise users of these subdomains
risk being locked out.
Setting an HSTS policy will also protect first time visitors who habitually
use search bars or search engines to reach their destination. For example,
typing “paypal” into Google’s HTTPS search engine will yield a link to
https://www.paypal.com, because Google will
always link to the HTTPS version of a website if an appropriate HSTS policy
HSTS is clearly an important security feature, but there are several
circumstances under which its benefits will not work. Because HSTS directives
are delivered via an HTTP header (over an HTTPS connection), HSTS can only instruct a browser to only use
HTTPS after the browser’s first visit to a secure website.
Men-in-the-middle can therefore still carry out attacks against users who
- Never before visited the site.
- Recently reinstalled their operating system.
- Recently reinstalled their browser.
- Switched to a new browser.
- Switched to a new device (e.g. mobile phone).
- Deleted their browser’s cache.
- Not visited the site within the past year (or however long the
These vulnerabilities can be eliminated by using HSTS Preloading,
which ensures that the site’s HSTS policy is distributed to supported browsers
before the customer’s first visit.
Website administrators can use the form at
to request for domains to be included in the HSTS Preload list maintained by
Google. Each site must have a valid certificate, redirect all HTTP traffic to
HTTPS, and serve all subdomains over HTTPS. The HSTS header served from each
site must specify a
max-age of at least 18 weeks (10,886,400 seconds) and
It can take several months for domains to be reviewed and propagated to the
latest stable versions of Firefox, Safari, Internet Explorer, Edge and Chrome.
When domains are added to the preload list, all users of these browsers will
benefit from the security offered by HSTS, even if they have never visited the
HSTS is widely supported, but not widely implemented. Nearly all modern browsers obey HSTS policies, including Internet Explorer 11,
Microsoft Edge, Firefox, Chrome, Safari and Opera – yet less than 5% of
secure websites enable this important security feature.
Secure websites that do not use HSTS are trivial to attack if the attacker can
hijack a victim’s web traffic, but it is even easier to defeat
such attacks by implementing an HSTS policy. This begs the question of why so
few websites are using HSTS.
The HSTS specification (RFC 6797)
was published in 2012, and so it can hardly be considered a new
technology any more. Nonetheless, many website administrators might still be
unaware of its existence, or may not yet feel ready to commit to running an
HTTPS-only website. These are probably the most significant reasons for its low
Some website administrators have even disabled HSTS by explicitly setting a
max-age of 0 seconds. This has the effect of switching off any previously established HSTS
policies, but this backpedalling can only take proper effect if every client revisits the secure site after
max-age has been set to zero. When a site
implements an HSTS policy, it is effectively committed to maintaining its HTTPS service for as long as the largest
max-age it has ever specified, otherwise it risks denying access to infrequent visitors.
Nearly 4% of all HTTPS servers that use the
header currently set a
max-age of zero, including Twitter’s
Browser support for HSTS can also introduce some privacy
concerns. By initiating requests to several distinct hostnames (some of which
enable HSTS), a hostile webpage can establish a
to uniquely identify the client browser during subsequent visits, even if the
user deletes the browser’s conventional cookies. The browser will remember which
pattern of hostnames had HSTS enabled, thus allowing the supercookie to persist.
However, this privacy concern only affects clients and does not serve as an
excuse for websites to avoid implementing their own HSTS policies.
Implementing an HSTS policy is very simple and there are no practical downsides
when a site already operates entirely over HTTPS. This makes it even more
surprising to see many banks failing to use HSTS, especially on their online
banking platforms. This demonstrates poor security practices where it matters
the most, as these are likely to be primary targets of pharming attacks.
Netcraft offers a range of services that can be used to detect and defeat large-scale pharming attacks, and security testing services that identify man-in-the-middle vulnerabilities in web application and mobile apps. Contact email@example.com for more information.
95% of HTTPS servers vulnerable to trivial MITM attacks
95% of HTTPS servers vulnerable to trivial MITM attacks