April 2019 Web Server Survey

In the April 2019 survey we received responses from 1,445,266,139 sites across 233,886,577 unique domain names and 8,613,630 web-facing computers. This reflects a loss of 16.8 million sites, but a gain of 1.72 million domains and 87,000 computers.

Most websites now use nginx!

Despite the overall loss of sites this month, nginx gained 22.3 million websites and 2.03 million additional active sites. nginx also gained the largest number of web-facing computers, increasing its total by 63,000 to 2.57 million (+2.52%). nginx's market share of web-facing computers is now nearly 30%, and this is continuing to grow steadily closer to Apache's leading share of 37.3%.

Microsoft and Apache lost shares in every headline metric this month, with both vendors contributing significantly to this month's overall loss of sites. Microsoft lost 18.9 million sites, while Apache lost 17.2 million, causing their shares to decrease by 1.01 and 0.87 percentage points.

These changes have pushed nginx into the lead, giving it a 27.5% share of all sites in Netcraft's April 2019 Web Server Survey. Significantly, this is the first time since 1996 that a vendor other than Microsoft or Apache has served the largest number of websites.

The reign of "a patchy" web server

If we cast our minds back to early 1996 (not long before the arrest of the Unabomber and the release of the Spice Girls' first cassette tape single), the most commonly used web server software was still NCSA HTTPd. This long-since discontinued web server was originally developed three years earlier by Rob McCool at the National Center for Supercomputing Applications; but when he left the NCSA in mid-1994, development stalled, prompting many webmasters to develop their own extensions and bug fixes.

A small group of these developers coordinated their changes in the form of patches, eventually leading to the foundation of the independent Apache Group. By April 1995, the group had made its first official public release of the Apache web server (version 0.6.2), which was based on NCSA HTTPd 1.3.

Although the NCSA resumed development of its own web server around the same time, Apache quickly took hold of the market. Exactly a year after Apache's first public release, Netcraft's April 1996 Web Server Survey showed that Apache had succeeded in overtaking NCSA's lead, marking the start of a remarkable uninterrupted 18-year reign.

The non-profit Apache Software Foundation, was later formed in 1999, and today is home to hundreds of other projects in addition to the Apache HTTP Server. Microsoft briefly took the lead from Apache in 2014, and retook the lead from 2016 until being beaten by nginx this month.

However, for now, Apache remains on top of every other headline metric: It leads with a 30.3% share of active sites, 37.3% of all web-facing computers, 31.5% of all domains, and it serves 32.2% of the top million websites. Nonetheless, nginx's strong and consistent growth makes it look set to challenge Apache's lead within a year or two. Most noticeably, it is rapidly catching up with Apache's declining share of web-facing computers, and may also soon threaten Apache's share of the top million websites.

New web server releases

There have been several new releases over the past month:

  • Apache 2.4.39 was released on 1 April. As usual, this latest release in the 2.4.x stable branch is regarded by the Apache Software Foundation to be the best available version; but more importantly, it resolves several security issues including an access control bypass and privilege escalation vulnerability.
  • nginx 1.15.10 mainline was released on 26 March, adding some new directives and certificate features. This was followed by two bugfix releases: nginx 1.15.11 on 9 April, and nginx 1.15.12 on 16 April.
  • njs 0.3.1 (the JavaScript-like scripting language that allows nginx functionality to be extended) was released on 16 April, adding several new features, including support for arrow functions.
  • OpenLiteSpeed 1.4.46 was released on 5 April, adding support for PHP7 and app servers that use nodeJS, Python and Ruby.
  • Taobao's Tengine 2.3.0 was released on 25 March. This development version of the open source nginx fork inherits all features from nginx 1.15.9 and includes several new features, changes and bugfixes.

Tengine Aserver

Visible uptake of the latest Tengine 2.3.0 development version is likely to be slow. The most commonly used numbered version is still 2.2.0, despite there being four newer development versions since its release more than three years ago; and development version 1.4.2, which was released in 2012, is not far behind.

Tengine 2.2.0 is currently used by 13.9% of all Tengine-powered websites, but the majority – 42.4% – do not reveal a version number at all, and a further 29.8% respond with the Tengine/Aserver server header. Nearly all of the websites that use Tengine Aserver are online stores hosted on subdomains of taobao.com and the domain of its parent company, alibaba.com, suggesting that it is a custom version designed specifically for these applications.

Development versions of Tengine appear to be far more popular than stable releases. The most recent stable version, Tengine 2.1.2, was released in December 2015 and is used by only 0.26% of all Tengine-powered websites.

Total number of websites

Web server market share

DeveloperMarch 2019PercentApril 2019PercentChange
nginx375,431,60625.68%397,728,88927.52%1.84
Apache403,603,74527.61%386,380,89326.73%-0.87
Microsoft381,017,77626.06%362,109,19625.05%-1.01
Google24,809,6821.70%25,956,0801.80%0.10
Continue reading

May 2019 Web Server Survey

In the May 2019 survey we received responses from 1,326,664,693 sites across 235,011,143 unique domain names and 8,726,985 web-facing computers. Although this reflects a gain of 1.12 million domains and 113,000 computers, there has been a loss of 119 million sites.

This month's relatively large drop in sites (-8.2%) includes a 10.3 million reduction in the number of websites that are served by nginx, just a month after it became the first vendor other than Microsoft and Apache to serve the largest number of websites over the past 23 years. As Apache lost only 696,000 sites this month, nginx is now only 1.73 million sites ahead, with a market share of 29.20% compared with Apache's 29.07%.

The sites metric has been particularly volatile for Microsoft, which was within two percentage points of Apache's share last month; but this month, it suffered a significant loss of 112 million (-30.8%) sites, leaving it more than 10 points behind with a market share of 18.9%.

Despite losing more than 10 million sites, nginx has outperformed every vendor in all other headline metrics this month – this includes a gain of 939,000 active sites, 1.06 million domains, 63,800 web-facing computers, and an additional 2,120 sites within the top-million websites. Apache continues to lead in all of these metrics, while nginx is in second place and closing, increasing its market share while Apache's declines.

Apache lost 4,330 entries from the top million sites this month, decreasing its share of that market to 31.8%, but leaving it still more than 5 percentage points ahead of nginx. Some of the highest-traffic users of Apache include FedEx, Orange, Slack, Adobe and Ubuntu, while prominent users of nginx include the likes of DuckDuckGo, the BBC, GitLab, and the bit.ly short link service.

The highest-traffic site, www.google.com, uses the in-house gws (Google Web Server), which is also used by many other top-million Google websites, including Google Maps and dozens of country-specific variants of the main search site – like google.de and google.nl.

Envoy

A relatively unfamiliar server called envoy has suddenly leapt into 10th place by sites after experiencing 500-fold growth, increasing its website count from just 10,300 to 5.10 million sites across 2.71 million distinct domains. The majority of these sites are hosted by SquareSpace, which provides easy-to-use website and online store building services that feature drag-and-drop layouts with ready-made templates.

Envoy is an open source edge and service proxy designed for cloud-native applications. It was originally built by the transportation network company Lyft, but Squarespace is now by far the most visible user of the product. Squarespace engineers pursued a self-service infrastructure with Kubernetes to handle the complexity of their software, but to keep up with growth and demand, they started integrating the Envoy proxy into their system more than a year ago to build a service mesh control plane – a policy that turns a set of isolated stateless sidecar proxies into a distributed system.

While this is the first survey in which Envoy has been seen en masse at Squarespace, it is possible that they have already been using it for a number of months without revealing the envoy server header.

cPanel

This month's survey also saw cPanel advance to 9th place with a total of 7.35 million sites. cPanel is a Linux-based web hosting control panel that provides a graphical interface for administering websites via a secure service on port 2083. Most cPanel-administered websites exhibit the bare cPanel server banner on HTTP port 80, but there are also 5.77 million Apache-powered sites that reveal the use of cPanel via Server headers similar to Apache/2.4.39 (cPanel) OpenSSL/1.0.2r mod_bwlimited/1.4.

While the cPanel interface is aimed at individual end users or hosting customers, the associated WHM (WebHost Manager) interface allows hosting providers to manage large numbers of cPanel user accounts and add custom branding to their customers' dashboards. A slightly cheaper cPanel Solo product also provides most cPanel and WHM features to hosting providers or individuals with only a single server account to manage. These products have led to cPanel being found across a variety of hosting locations in more than 150 countries, ranging from more than 400,000 cPanel-powered sites operated by a single French hosting company, to a single cPanel-powered website in the whole of Zambia.

New web server releases

  • nginx 1.16.0 was released on 23 April 2019. In keeping with nginx tradition, this first release in the 1.16.x stable branch includes all of the new features and bug fixes that were introduced in the 1.15.x mainline branch – this means it has improved UDP proxying, support for TLS 1.3 early data and dynamic loading of TLS certificates amongst other features.

  • Envoy 1.10.0 was released on 5 April 2019, enabling TLS 1.3 on the server-side, and making a multitude of other changes and additions. The previous release, 1.9.1, addressed two vulnerabilities – CVE-2019-9900 and CVE-2019-9901– both of which could have allowed remote attackers to bypass access control rules.

  • GoDaddy is currently using DPS 1.6.0 to serve customer sites that have been created with its Website Builder tool. This server software continues to be updated fairly frequently: the sites were using DPS 1.5.11 when this month's survey data was originally collected, and DPS 1.5.7 during last month's survey.

Total number of websites

Web server market share

DeveloperApril 2019PercentMay 2019PercentChange
nginx397,728,88927.52%387,416,88929.20%1.68
Apache386,380,89326.73%385,685,25229.07%2.34
Microsoft362,109,19625.05%250,440,88718.88%-6.18
Google25,956,0801.80%27,711,3752.09%0.29
Continue reading

95% of HTTPS servers vulnerable to trivial MITM attacks

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 DROWN attack.

Background

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.

A man-in-the-middle attack like this is generally not possible if the customer uses HTTPS.

A man-in-the-middle attack like this is generally not possible if the initial request from the customer uses HTTPS.

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 websites.

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.

NatWest's online banking website at www.nwolb.com lacks an HSTS policy and also offers an HTTP service to redirect its customers to the HTTPS site. This setup is vulnerable to the type of man-in-the-middle attack described above.

NatWest's online banking website at www.nwolb.com lacks an HSTS policy and also offers an HTTP service to redirect its customers to the HTTPS site. This setup is vulnerable to the type of man-in-the-middle attack described above.

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:

    Strict-Transport-Security: max-age=31536000;

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 HTTPS instead.

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.

When Google Chrome encounters an invalid certificate for a site that has an effective HSTS policy, the victim is not allowed to bypass the browser's warning message or add an exception.

When Google Chrome encounters an invalid certificate for a site that has an effective HSTS policy, the victim is not allowed to bypass the browser's warning message or add an exception.

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 exists.

HSTS preloading

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 have:

  • 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 max-age period lasts).

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 https://hstspreload.appspot.com/ 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 include the preload and includeSubdomains directives.

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 sites before.

Conclusions

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 uptake.

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 the 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 Strict-Transport-Security header currently set a max-age of zero, including Twitter's t.co URL-shortener.

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 "supercookie" 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 security-sales@netcraft.com for more information.

Google’s POODLE affects oodles

97% of SSL web servers are likely to be vulnerable to POODLE, a vulnerability that can be exploited in version 3 of the SSL protocol. POODLE, in common with BEAST, allows a man-in-the-middle attacker to extract secrets from SSL sessions by forcing the victim's browser into making many thousands of similar requests. As a result of the fallback behaviour in all major browsers, connections to web servers that support both SSL 3 and more modern versions of the protocol are also at risk.

The Secure Sockets Layer (SSL) protocol is used by millions of websites to protect confidential data in transit across the internet using strong cryptography. The protocol was designed by Netscape in the mid 1990s and was first released to the public as SSL 2 in February 1995. It was quickly replaced by SSL 3 in 1996 after serious security flaws were discovered. SSL 3 was replaced by the IETF-defined Transport Layer Security (TLS) version 1.0 in January 1999 with relatively few changes. Since TLS 1's release, TLS 1.1 and TLS 1.2 have succeeded it and should be used in its place wherever possible.

sslv3-vulnerable6

POODLE's bark may be worse than its bite

Unlike Heartbleed, POODLE can be used to attack client-server connections and is inherent to the protocol itself, rather than any one implementation such as OpenSSL or Microsoft's SChannel. In order to exploit it, an attacker must modify the victim's network traffic, know how the targeted secret information is structured (such as where a session cookie appears) and be able to force the victim into making a large number of requests.

Each SSL connection is split up into a number of chunks, known as SSL records. When using a block cipher, such as Triple DES in CBC mode, each block is mixed in with the next block and the record then padded to be a whole number of blocks long (8-bytes in the case of Triple DES). An attacker with network access can carefully manipulate the ordering of the cipher-blocks within a record to influence the decryption and exploit the padding oracle. If the attacker has been lucky (there's a 1 in 256 chance), she will have matched the correct value for the padding length in her manipulated record and correctly guessed the value of a single byte of the secret. This can be repeated to reveal the entire targeted secret.

SSL 3's padding is particularly easy to exploit as it relies on a single byte at the end of the padding, the padding length. Consequently an attacker must force the victim to make only 256×n requests for n bytes of secret to be revealed. TLS 1.0 changed this padding mechanism, requiring the padding bytes themselves to have a specific value making the attack far less likely to succeed.

The POODLE vulnerability makes session hijacking attacks against web applications reasonably feasible for a correctly-positioned attacker. For example, a typical 32-byte session cookie could be retrieved after eavesdropping just over 8,000 HTTPS requests using SSL 3. This could be achieved by tricking the victim into visiting a specially crafted web page which uses JavaScript to send the necessary requests.

Use of SSL v3

Within the top 1,000 SSL sites, SSL 3 remained very widely supported yesterday, with 97% of SSL sites accepting an SSL 3 handshake. CitiBank and Bank of America both support SSL 3 exclusively and presumably are vulnerable.

move-to-tls1

A number of SSL sites have already reacted to this vulnerability by disabling support for SSL 3, including CloudFlare and LinkedIn. On Tuesday 14th, the most common configuration within the top 1,000 SSL sites was to support SSL 3.0 all the way through to TLS 1.2, with almost two-thirds of popular sites taking this approach. One day later, this remains the most popular configuration; however, TLS 1.0 is now the minimum version for 11%.

Microsoft Internet Explorer 6 does not support TLS 1.0 or greater by default and may be the most notable victim of disabling SSL 3 internet-wide. Now 13 years old, IE6 was the default browser released with Windows Server 2003 and Windows XP in 2001 and will remain supported in Windows Server 2003 until July 2015. Despite its age and the end of Microsoft's support for Windows XP, IE6 remains popular, accounting for more 3.8% of web visits worldwide, and 12.5% in China. This vulnerability may ring the death knell for IE6 and Windows XP.

However, unless SSL 3 is completely disabled on the server side, a client supporting SSL 3 may still be vulnerable even if the server supports more recent versions of TLS. An attacker can take advantage of browser fallback behaviour to force otherwise secure connections to use SSL 3 in place of TLS version 1 or above.

SSL version negotiation

At the start of an SSL connection, servers and clients mutually agree upon a version of SSL/TLS to use for the remainder of the connection. The client's first message to the server includes its maximum supported version of the protocol, the server then compares the client's maximum version against its own maximum version to pick the highest mutually supported version.

While this mechanism protects against version downgrade attacks in theory, most browsers have an additional fallback mechanism that retries a connection attempt with successively lower version numbers until it succeeds in negotiating a connection or it reaches the lowest acceptable version. This additional fallback mechanism has proven necessary for practical interoperability with some TLS servers and corporate man-in-the-middle devices which, rather than gracefully downgrading when presented with a non-supported version of TLS, they instead terminate the connection prematurely.

An attacker with appropriate network access can exploit this behaviour to force a TLS connection to be downgraded by forging Handshake Alert messages. The browser will take the Handshake Alert message as a signal that the remote server (or some intermediate device) has version negotiation bugs and the browser will retry the connection with a lower maximum version in the initial Client Hello message.

handshake-alert

Operation of a forced downgrade to SSL 3 against a modern browser.

The fallback mechanism was previously not a security issue as it never results in the use of a protocol version that neither the client nor server will accept. However, those with clients that have not yet been updated to disable support for SSL 3 are relying on the server to have disabled SSL 3. What remains is a chicken and egg problem, where modern clients support SSL 3 in order to retain support for legacy servers, and modern servers retain support for SSL 3 for legacy clients.

There is, however, a proposed solution in the form of an indicator (an SCSV) in the fallback connection to inform compatible servers that this connection is a fallback and to reject the connection unless the fallback was expected. Google Chrome and Google's web sites already support this SCSV indicator.


Firefox 32

Chrome 40

IE 11

Opera 25

Safari 7.1
TLS 1.2 TLS 1.2 x 3 TLS 1.2 TLS 1.2 x 3 TLS 1.2
TLS 1.1 TLS 1.1 TLS 1.1
TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0
SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0

Comparison of browser fallback behaviour

We tested five major browsers with an attack based on the forged Handshake Alert method outlined above, and found that each browser has a variant of this fallback behaviour. Both Chrome and Opera try TLS 1.2 three times before trying to downgrade the maximum supported version, whereas the remainder immediately started downgrading. Curiously, Internet Explorer and Safari both skip TLS 1.1 and jump straight from TLS 1.2 to TLS 1.0.

Mitigation

Mitigation can take many forms: the fallback SCSV, disabling SSL 3 fallback, disabling SSL 3 in the client side, disabling SSL 3 in the server side, and disabling CBC cipher suites in SSL version 3. Each solution has its own problems, but the current trend is to disable SSL 3 entirely.

Disabling only the CBC cipher suites in SSL 3 leaves system administrators with a dilemma: RC4 is the only other practical choice and it has its fair share of problems making it an undesirable alternative. The SCSV requires support from both clients and servers, so may take some time before it is widely deployed enough to mitigate this vulnerability; it will also likely not be applied to legacy browsers such as IE 6.

Apache httpd can be configured to disable SSL 3 as follows:

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3
Microsoft IIS and nginx can also be configured to avoid negotiating SSL version 3.

Firefox can be configured to disable support for SSL 3 by altering security.tls.version.min from 0 (SSL 3) to 1 (TLS 1) in about:config.

firefox-disable

Internet Explorer can also be configured to disable support using the Advanced tab in the Internet Options dialogue (found in the Control Panel). In a similar way, IE 6 users can also enable support for TLS 1.0.

internet-options-disable

Chrome can be configured to not use SSL 3 using a command line flag, --ssl-version-min=tls1.

Site Report

You can check which SSL sites are still using SSL 3 using the Netcraft Site Report:

Netcraft site report
URL:

Ask.fm users being redirected to malware sites

Malicious adverts displayed on the Ask.fm website have been automatically redirecting users to malware sites, where they are prompted to install unwanted or malicious software under the pretense of Java and Flash Player updates.

This particular advert is benign and serves only as an example of the banner's placement

Ask.fm is a popular social network which allows its users to receive and answer anonymous questions, but both registered users and anonymous question askers are being put at risk by some of the adverts it displays: Merely viewing a user's profile on Ask.fm caused some users to be redirected to the following page, which claimed that an outdated Java plugin had been detected (even when Java had been disabled).

Rather than downloading a Java update, victims will instead end up installing a program which several anti-virus vendors identify as DomaIQ. This is an advertising platform used by adware and other malicious programs to display unwanted pop-up ads within Internet Explorer, Firefox and Google Chrome.

The rogue advert responsible for performing the redirection was initially served through ADTECH GmbH, which is a wholly-owned subsidiary of AOL. However, the trail does not end there – the framed content served by ADTECH subsequently requested several pages from AppNexus servers at ib.adnxs.com and ams1.ib.adnxs.com, before one of these pages initiated a request to a Java servlet on exchange.admailtiser.com. Finally, this servlet page caused the parent frame to be redirected from Ask.fm to the page on www.updriong.com, essentially taking the browser to a different website without requiring any user interaction.

After returning to the Ask.fm website, another rogue advert immediately redirected the browser to a fake Adobe Flash update site. Again, no user interaction was required – the chain of requests initiated by the third party advert automatically redirected the user's browser to the fake site hosted in Sweden.

In this case, the rogue advert on http://ask.fm/account/wall was again initially served by ADTECH, but the framed content made its next request to a Yahoo ad server (ads.yahoo.com), which in turn made a request to ad.copa-media.com, which itself made a request for content hosted on an AppNexus server at ams1.ib.adnxs.com.

Finally, a request to another AppNexus server at ib.adnxs.com resulted in the user's browser being redirected to the fake Adobe Flash update site at download.adoocobo.us. The setup.exe file is served from a domain which is known for propagating malware.

Mobile browsers have also been targeted by similar attacks on Ask.fm. The example below shows an Ask.fm webpage displaying an intrusive and unsolicited alert dialog which originates from a Yahoo ad server. If the user clicks OK, he will be taken to a site which falsely claims that his phone has severe battery issues.

Within a few minutes, another advert on Ask.fm attempted to download an Android app directly from a website in France as soon as the user clicked OK. The makers of the genuine Mobogenie Market app recommend that it should only be downloaded from reliable sources such as Google Play, mobogenie.com and other partner networks (although it does not specify who these are).

Incidentally, despite encouraging its users not to reveal their passwords to anyone, the login form on http://ask.fm transmits a user's password over an unencrypted HTTP connection:

Most high profile websites only ever transmit passwords over encrypted HTTPS connections, and many sites also ensure that the entire duration of a browser session remains encrypted, i.e. not just the login process. Sending plain text passwords over an unencrypted connection makes them vulnerable to eavesdropping, giving a correctly-positioned attacker the opportunity to gain unauthorised access to Ask.fm user accounts.

June 2019 Web Server Survey

In the June 2019 survey we received responses from 1,333,421,275 sites across 236,991,999 unique domain names and 8,840,331 web-facing computers. This reflects gains of 6.76 million sites, 1.98 million domains, and 113,000 computers.

nginx has further extended its lead in the hostnames metric, with 52.2 million additional sites pushing its total up to 440 million. Since overtaking Apache in April, nginx has already built up a 4.89 percentage point lead over Apache's market share and is not far off accounting for more than one third of all sites.

Apache retains the lead in all other metrics, but for how long? The proportion of unique domains that are served by Apache has fallen to 30.1%, while nginx snapped up the majority of this month's net domain growth, bringing its share to within 3.4 percentage points of Apache's. There has been a clear trend of Apache's domain market share decreasing, while nginx's increases and looks likely to overtake Apache within a year. A similar trend is evident in web-facing computers and among the top million sites, so it may not be long before nginx steals more of the limelight.

Reports of a remote code execution vulnerability in most recent versions of nginx were downplayed by its developers, who claimed that neither of the two overflow vulnerabilities appeared to be generally exploitable. Both bugs affected the njs scripting language implementation that allows nginx's functionality to be extended; one bug was fixed in njs 0.3.2, which was released on 21 May along with nginx 1.17.0, while the other bug is expected to be fixed in the future release of njs 0.3.3.

Several other product updates were also released during May, including NGINX Unit 1.9.0, lighttpd 1.4.54, LiteSpeed Web Server 5.3.8 (Stable), OpenLiteSpeed 1.5.1, and cPanel & WHM 80. The latest version of cPanel & WHM adds the ability to run Node.js applications, manage API tokens to allow resellers and third-party developers to run API functions, and ensure visitors are redirected to the secure HTTPS versions of sites.

Envoy – the open source edge and service proxy for cloud-native applications, which leapt to prominence in last month's survey – remains in tenth place with around 5 million sites, which are spread across 2.7 million unique domain names.

Cloudflare's web server has moved up into fifth place after gaining more than 5 million websites, giving it a total of 35.1 million sites across 12.9 million domains. The Cloudflare server is used by the edge nodes of Cloudflare's content delivery network, which now serves 2.6% of all sites in this month's survey.

Microsoft saw losses in every metric this month, apart from web-facing computers, where it made a gain of 13,600; however, this was not enough to stop its market share falling slightly, while Apache gained 17,300 computers and nginx gained 64,000.

Total number of websites

Web server market share

DeveloperMay 2019PercentJune 2019PercentChange
nginx387,416,88929.20%439,626,71332.97%3.77
Apache385,685,25229.07%374,360,94928.08%-1.00
Microsoft250,440,88718.88%205,235,29115.39%-3.49
Google27,711,3752.09%28,181,7442.11%0.02
Continue reading