Most Reliable Hosting Company Sites in October 2014

Rank Performance Graph OS Outage
DNS Connect First
1 ServerStack Linux 0:00:00 0.019 0.093 0.079 0.155 0.155
2 XILO Communications Ltd. Linux 0:00:00 0.022 0.210 0.065 0.131 0.227
3 Linux 0:00:00 0.022 0.156 0.067 0.149 0.149
4 Linux 0:00:00 0.022 0.225 0.087 0.175 0.175
5 Qube Managed Services Linux 0:00:00 0.026 0.110 0.040 0.082 0.082
6 EveryCity SmartOS 0:00:00 0.026 0.092 0.067 0.136 0.136
7 iWeb Linux 0:00:00 0.026 0.146 0.080 0.157 0.157
8 LeaseWeb Linux 0:00:00 0.030 0.188 0.026 0.065 0.065
9 Bigstep Linux 0:00:00 0.030 0.138 0.062 0.127 0.127
10 Datapipe FreeBSD 0:00:00 0.037 0.108 0.018 0.036 0.054

See full table

ServerStack had the most reliable hosting company website in October with five failed requests. This is the eighth time this year that ServerStack has made it to the top 10 and the third time it has topped the table since we started monitoring it in 2012 — the last time ServerStack was at the top spot was back in June 2013. ServerStack is focussed on managed hosting and was co-founded by Moisey and Ben Uretsky who later went on to start cloud provider DigitalOcean.

XILO had the second most reliable company website with six failed requests. and also had the same number of failed requests, with the tie being broken by average connection time. This is the second time this year that British-based XILO has made it into the top 10. Its long-term uptime record backs up this recent strong performance — XILO has maintained 99.98% uptime over three years. had the third most reliable company website. Krystal provides modern, KVM-based virtualised Kloud servers from its data centre in an ex-military bunker outside London. This focus on security may be part of the reason why Krystal is trusted by Nike, The Financial Times, and The Telegraph to provide hosting services.

Linux remains the most common choice of operating system, being used by 8 of the top 10 hosting company websites. FreeBSD only had a single entrant, Datapipe, as did SmartOS with EveryCity.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

DigitalOcean: 4th largest hosting company in under 2 years

The number of web-facing computers hosted by DigitalOcean has grown by nearly 400% over the past year, making it the fourth largest hosting company in the world.

Even more remarkable is that this position has been achieved completely from scratch in less than two years — DigitalOcean first appeared in our survey in December 2012, when it had only 138 web-facing computers. Now it has more than 100,000 computers, and has recently overtaken well-established hosting companies such as Rackspace and Hetzner, despite their considerable head starts over DigitalOcean.

DigitalOcean growth

Growth at DigitalOcean

  Dec 2012 Apr 2013 Oct 2013 Apr 2014 Oct 2014
Computers 138 2,821 22,491 63,436 108,489
Active Sites 237 5,547 66,230 161,994 286,342
Hostnames 328 73,827 336,615 1,522,539 2,044,827

DigitalOcean provides SSD-backed virtual computers (called "droplets") which are available at relatively low hourly rates, making it an attractive hosting location for hobbyists and large companies alike. Coupled with promotional voucher codes which offer free credit to new users, these low costs have likely played a big part in DigitalOcean's rapid growth. If current growth rates persist, DigitalOcean is likely to become the third largest hosting company within the next few months, and could well be biting at the heels of second-place OVH early next year.

Only Amazon has grown faster over the past 12 months, putting its lead well out of DigitalOcean's reach — at least for the time being. DigitalOcean's attractive pricing has no doubt been putting pressure on Amazon, who introduced a new general purpose instance type for Amazon Elastic Compute Cloud (EC2) before announcing lower-than-expected Q2 results. The new "t2.micro" instances are the lowest-cost option at Amazon, costing $0.013 per hour, but do not include persistent storage by default.

These changes have brought the virtual hardware costs of Amazon EC2 almost on par with DigitalOcean, where a droplet with 1GB RAM and 30 GB of SSD storage currently costs $10 per month. A comparable t2.micro instance on Amazon EC2 would cost around $12 per month. However, the biggest difference is likely to manifest itself in the cost of bandwidth: The $10 DigitalOcean droplet includes 2TB of data transfer, whereas Amazon charges up to $0.12 per GB of outbound data transfer beyond the first GB. If both were used to serve 2TB of data to the internet, DigitalOcean's droplet cost would still only be $10, whereas Amazon's would skyrocket to more than $250.

With price wars in full swing, it will be interesting to see how other hosting companies try to compete in this rapidly growing market. DigitalOcean already offers a cheaper, less powerful droplet at $5/month, but even lower spec virtual machines can be found for significantly less –, for example, offers instances with 256MB RAM and 10GB of storage from only $0.99/month, and Amazon's AWS Free Tier provides up to 12 months of free, hands-on experience with several AWS services, including up to 750 hours per month of t2.micro usage.

Website growth

The number of websites hosted at DigitalOcean has followed a similar trend to its computer growth since mid-2013. More than two million websites are now hosted at DigitalOcean — a gain of more than 500% over the past 12 months. Around 14% of these sites are active, giving a surprisingly low ratio of active sites to computers (2.6:1).

In comparison, Amazon hosts an average of 8 active sites per computer, while Rackspace has 12. Just over half of DigitalOcean's web facing computers host only one website each.

DigitalOcean growth (logarithmic scale)

DigitalOcean's one-click apps may account for many of the computers which host only one website, as these allow customers to rapidly deploy a single application on a single Ubuntu droplet without significant knowledge of system administration. Popular web applications such as WordPress, Magento, Drupal and Django can be deployed, and the uptake appears to be significant — for instance, Netcraft's survey found that more than 23% of the active sites hosted at DigitalOcean are running WordPress, compared with less than 10% of all other active sites around the world.

Cloud hosting locations

Both DigitalOcean and Amazon provide a choice of data centers around the world, but the countries in which these are located do not completely overlap. For example, DigitalOcean droplets can now be provisioned in its London data center (LON1), which was introduced in July 2014 following requests from customers.

Amazon does not provide EC2 hosting in the UK, giving DigitalOcean a distinct advantage in this particular cloud hosting market. Despite being relatively new to the UK, DigitalOcean already ranks 22nd in terms of web-facing computers, and could soon become one of the largest hosting companies in the UK if its growth in Singapore is anything to go by. Its Singapore data center was opened in February 2014, and already has 6,600 web-facing computers, which is second only to Amazon's 12,900 computers — this is no mean feat considering Amazon has had data centers in Singapore since April 2010.

DigitalOcean added a London data center in July 2014
DigitalOcean regions - now includes London

Conversely, Amazon has a distinct advantage in Latin America, where it has the third largest number of web-facing computers. Despite receiving over 2,000 requests to open a Brazilian data center (four times as many requests as there were for a UK one), DigitalOcean does not look set to follow Amazon's footsteps any time soon: Brazilian import taxes would add around 100% to the cost of hardware, visa constraints would hamper the ability to review suitable data centers, and bandwidth not only costs more, but also has limited connectivity.

Netcraft provides information on internet infrastructure, including the hosting industry, and web content technologies. For information on the cloud computing industry visit

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.


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.


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.


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


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.


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

October 2014 Web Server Survey

In the October 2014 survey we received responses from 1,028,932,208 sites, which is nearly six million more than last month.

Apache regains the lead

Microsoft lost the lead to Apache this month, as the two giants continue to battle closely for the largest share of all websites. Apache gained nearly 30 million sites, while Microsoft lost 22 million, causing Apache to be thrust back into the lead by more than 36 million sites. In total, 385 million sites are now powered by Apache, giving it a 37.45% share of the market.

A significant contributor to this change was the expiry of domains previously used for link farming on Microsoft IIS servers. The domains used by these link farms were acquired and the sites are now hosted on Apache servers at Confluence-Networks, which display Network Solutions parking notices.

A new major release in the Apache 2.2 legacy branch was announced on 3 September. Apache 2.2.29 also incorporates many changes — including several security fixes — from version 2.2.28, which was not officially released. New versions of nginx stable and mainline were also released during September, which included fixes for an SSL session reuse vulnerability, plus several other bugfixes.

Top million sites

The million busiest websites now represent less than 0.1% of all websites in the survey, but provide an insight into the preferences amongst the sites which are responsible for the great majority of today's web traffic.

Just over half (50.2%) of the top million sites use Apache, which is very similar to its share amongst all active sites; however, nginx's market share is skewed noticeably higher amongst the top million sites, where it powers 20.3% of sites, compared with only 14.3% of all active sites.

Computer growth

The most stable metric is the market share of web-facing computers — hundreds of thousands of websites can easily be served from a single computer (and subsequently disappear all in one go) but it is obviously far less trivial and less desirable to deploy or decommission a significant number of computers. Netcraft's survey is also able to identify distinct computers which use multiple web-facing IP addresses, which adds further stability.

Apache leads in this market with a 47.5% share, and Microsoft also performs well with 30.7%, but both have been gradually falling over the past few years as a result of nginx's strong growth. nginx gained more than 17,000 additional web-facing computers this month, helping to bring its market share up to 10.3%.

New top level domains

The relatively new .xyz domain, which showed tremendous growth over the past couple of months, has started to flatten out slightly after gaining only 33,000 sites this month (+8%). Nonetheless, this is still quite a healthy gain, albeit notably less than last month's growth of 177,000 hostnames which then boosted its total by 78%.

Other promising TLDs include .london, .hamburg and .公司, each of which had fewer than 50 sites in last month's survey, but now have 17,000, 11,000 and 10,000 sites respectively.

The internationalised .公司 (.xn--55qx5d) TLD is delegated to the Computer Network Information Center of Chinese Academy of Sciences. It means "company", making it the Chinese equivalent of .com.

Total number of websites

Web server market share

DeveloperSeptember 2014PercentOctober 2014PercentChange
Continue reading

Phishing with data: URIs

A recent spate of phishing attacks has taken to using the data URI scheme for evil. Supported in most browsers, these special URIs allow the content of a phishing page to be contained entirely within the URI itself, effectively eliminating the need to host the page on a remote web server and adding an additional layer of indirection.

One of these attacks is demonstrated below, where a phishing campaign was used to herd victims to a compromised site in the US, which then redirected them to a Base64-encoded data URI. This particular example impersonates Google Docs in an attempt to steal email addresses and passwords from Yahoo, Gmail, Hotmail, and AOL customers.

Google Docs phishing site using data: URI

All of the attacks use Base64-encoded data URIs, rather than human-readable plain text, making it harder for people, simple firewalls and other content filters to detect the malicious content.

Most phishing sites are hosted on compromised websites, but can also be seen using purpose-bought domain names and bulletproof hosting packages that have been paid for fraudulently. However, fraudsters can take advantage of open redirect vulnerabilities to "host" these malicious data URIs without the need for conventional web hosting.

This situation is ideal for scenarios such as malware delivery and social engineering attacks where no subsequent client-server interaction is required, but phishing sites still need some way of transmitting their victim's credentials to the fraudster. Most phishing attacks that use data URIs resort to the traditional method of transmitting stolen credentials, i.e. POSTing them to a script on a remote web server. However, with no obvious phishing content being hosted on the remote web server, such scripts could be more difficult for third parties to take down; and as long as they remain functional, each one can continue to be used by any number of data URI attacks.

Another interesting example which impersonated an eBay login page is shown below. If a victim is unfortunate enough to fall for this particular phishing attack, his credentials will be transmitted to a PHP script hosted on a compromised web server in Germany.

eBay phishing site using a data: URI

This demonstrates an interesting deficiency in Google Chrome: If the data URI is longer than 100,000 characters, then none of the Base64-encoded data within the URI will be displayed in the address bar. Rather than truncating the URI, Chrome's address bar will only display the string "data:".

This behaviour could make it more difficult for wary victims to report such attacks. Although the victim is viewing an eBay phishing page, if he tries to copy the URI from the address bar in Chrome, the clipboard will still only contain the string "data:".

The Netcraft Extension provides protection against the redirects used in the phishing attacks above, and Netcraft's open redirect detection service can be used to identify website vulnerabilities which would allow fraudsters to easily redirect victims to similar phishing content.

Most Reliable Hosting Company Sites in September 2014

Rank Performance Graph OS Outage
DNS Connect First
1 Qube Managed Services Linux 0:00:00 0.004 0.086 0.023 0.046 0.046
2 Inc Linux 0:00:00 0.013 0.149 0.012 0.200 0.205
3 Memset Linux 0:00:00 0.013 0.111 0.055 0.132 0.217
4 Linux 0:00:00 0.013 0.242 0.080 0.159 0.159
5 Swishmail FreeBSD 0:00:00 0.022 0.124 0.073 0.144 0.186
6 ServerStack Linux 0:00:00 0.022 0.081 0.076 0.151 0.151
7 Datapipe FreeBSD 0:00:00 0.030 0.102 0.016 0.032 0.048
8 EveryCity SmartOS 0:00:00 0.030 0.083 0.054 0.107 0.107
9 Logicworks Linux 0:00:00 0.030 0.143 0.073 0.152 0.340
10 Pair Networks FreeBSD 0:00:00 0.030 0.219 0.082 0.166 0.579

See full table

Qube had the most reliable company site in September with only a single failed request. This is the fourth time this year that Qube has made it to first place, nudging ahead of Datapipe's track record this year. Qube offers a Hybrid cloud service, where physical servers and equipment are integrated with its cloud hosting with a secure connection between the two networks.

The second most reliable hosting company site belonged to GoDaddy, the world's largest domain registrar, and had only 3 failed requests in September. Memset and dinahosting also had only 3 failed requests and thus they were ranked by average connection times.

In third place is Memset. Memset was last ranked in the top 10 in June 2013 when it achieved 9th place with 6 failed requests. Memset offers its customers a Perimeter Patrol service, which involves regular scanning of Memset servers to highlight security vulnerabilities.

Linux was still the most popular operating system of choice, used by 6 of the top 10, followed by FreeBSD which was used by 3. EveryCity, however, uses SmartOS, a community fork of OpenSolaris geared towards cloud hosting using KVM virtualisation.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.