President Obama forgets to renew SSL certificate

At the start of the first US Government shutdown since 1996, an SSL certificate used on barackobama.com has expired. Issued by Go Daddy in September 2012, the SSL certificate for *.barackobama.com and barackobama.com was used by Organizing for Action, a non-profit grassroots organisation aligned with Obama's political policies. Whilst not directly associated with the US Government, the expiry of the SSL certificate for barackobama.com during a US Government shutdown is nonetheless a curious coincidence.

Warning in Google Chrome when visiting a website using the SSL certificate for *.barackobama.com.

Several SSL certificates controlled by the US Government expired today and are still being used — for example, the SSL certificates used on both ui.tn.gov and webmail.coop-uspto.gov have expired and may not be replaced any time soon. Furthermore, there are at least 30 US Government sites still using SSL certificates that are scheduled to expire before Friday.

SSL certificates expiring may be least of the problems for US Government websites, some websites have been taken offline: www.nasa.gov now redirects to notice.usa.gov.

Most Reliable Hosting Company Sites in September 2013

Rank Performance Graph OS Outage
hh:mm:ss
Failed
Req%
DNS Connect First
byte
Total
1 Qube Managed Services Linux 0:00:00 0.000 0.125 0.066 0.134 0.134
2 Kattare Internet Services Linux 0:00:00 0.003 0.193 0.125 0.250 0.515
3 Hosting 4 Less Linux 0:00:00 0.003 0.179 0.128 0.251 0.634
4 www.uk2.net Linux 0:00:00 0.006 0.158 0.087 0.179 0.309
5 krystal.co.uk Linux 0:00:00 0.009 0.151 0.100 0.208 0.208
6 Netcetera Windows Server 2012 0:00:00 0.022 0.073 0.088 0.185 0.357
7 iWeb Linux 0:00:00 0.022 0.152 0.089 0.177 0.177
8 Hivelocity Hosting unknown 0:00:00 0.022 0.156 0.101 0.201 0.201
9 ServerStack Linux 0:00:00 0.025 0.099 0.081 0.161 0.161
10 INetU Windows Server 2003 0:00:00 0.025 0.143 0.088 0.221 0.484

See full table

Qube Managed Services had the most reliable hosting company site in September 2013, with not a single failed request throughout the whole month, and an average connection time of only 0.066 seconds. Qube is based in London, but they also host services from data centers in New York and Zurich. Their New York data center is at 111 8th Avenue, which is adjacent to a trunk dark fiber line. This building is the city's third largest in terms of floor area and was bought by Google for $1.9 billion in 2010. Qube provides managed and colocated hosting services from each of its data centers, as well as virtual data centers based on VMware vCloud Director.

Including September, Qube ("Qualified By Experience") has made five appearances within the top ten so far this year, and also attained another first place result in May.

In second place, with just one failed request, was Kattare Internet Services. It is among the most reliable sites monitored by Netcraft, managing 99.993% uptime over the past year and 99.97% over the past seven years. On September 21st, it was predicted that a damaging storm would hit the Pacific Northwest (Kattare's base of operations), causing thunder and wind storms, with 50mph gusts strong enough to take down trees. The next day this storm took out Kattare's power supply; however, the use of generators meant there were no outages recorded during the storm.

Hosting 4 Less narrowly missed out on second place, as although it only had one failed request during September, its average connection time was 3 milliseconds slower than Kattare's.

Seven of September's top ten hosting company sites were running on Linux operating systems. Five of these (including Qube, Kattare and Hosting 4 Less) used the Apache web server software, while ServerStack and krystal.co.uk used nginx.

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.

Wildcard EV certificates supported by major browsers

Extended Validation, or EV, certificates are designed to provide evidence of a greater level of verification by the Certificate Authority of the legal identity of the company in control of the SSL certificate and domain name. By way of contrast, the most common type of certificate, domain-validated, only requires the CA to verify control of the domain name. Browsers display EV-specific cues within the user interface to highlight this additional verification: most notably, the company name is displayed in the address bar, often with a green padlock or a green bar.

An Extended Validation certificate for login.live.com in Google Chrome

EV certificates are subject to additional requirements, over and above those specified in the Baseline Requirements. As with the Baseline Requirements, the EV guidelines were drawn up by the CA/B forum, an industry group of both browser vendors and CAs. The EV guidelines prohibit EV certificates from using wildcards (i.e. www.example.com, mail.example.com, and paypal.example.com would all match *.example.com) and explicitly mention this restriction twice "Wildcard certificates are not allowed for EV Certificates".

Nevertheless, Verizon Business has chosen to test browsers' approach to wildcard EV certificates by issuing a certificate to Accenture for *.cclearning.accenture.com. Verizon Business — which is not a member of the CA/B forum — is known for its maverick approach to certificate issuance having issued certificates (including EV certificates) which violate the Baseline Requirements.

Despite the EV guidelines prohibiting wildcard EV certificate issuance, presently most major browsers fail to enforce this restriction. Google Chrome, Firefox, Internet Explorer, Opera, and Safari (Desktop) all retain the EV browser cues when visiting a website using this EV certificate.

Clockwise from top left: Google Chrome, Internet Explorer, Opera, and Firefox. All display the conventional EV browser cues.

The only exception was Safari — Desktop Safari displays the EV browser cues as normal, as do the remainder of the desktop browsers; however, Safari on iOS 7 does not display the EV UI.

Safari (Desktop)

Safari on iOS 7 does not display the conventional EV UI for the wildcard EV certificate. An example of the EV UI in iOS 7.

Netcraft offers a Baseline Requirements checking service for CAs to provide third-party verification of Baseline Requirements conformance. For more information contact sales@netcraft.com

Certificate Authorities struggle to comply with Baseline Requirements

SSL Certificate Authorities (CAs) are responsible for issuing the SSL certificates which are used to protect billions of secure transactions across the internet against eavesdroppers and impersonators. The CA/B forum — a group of CAs and browser vendors — drew up the Baseline Requirements in 2011 outlining a set of minimum standards to which all CAs should operate.

Since the "effective date" of the document, 1st July 2012, compliance with the Baseline Requirements has been mixed — Netcraft has previously discovered non-compliant certificates, including short RSA public keys and irrevocable certificates. More than a year on and several months after Mozilla incorporated the Baseline Requirements into its CA policy (albeit with a transition period allowed) CAs are still issuing non-compliant certificates.

By examining the certificates found in Netcraft's SSL Survey and evaluating them against a small subset of rules extracted from the Baseline Requirements document, Netcraft found more than 2,500 non-compliant certificates. The non-complaint certificates fall into one or more of the categories described below: some of the problems are serious security vulnerabilities, and others are less critical but are still violations of the Baseline Requirements.

  • Short RSA public key — the shorter a public key is; the easier it is for an attacker (such as the NSA) to brute-force the secret private key, and hence decrypt communication. NIST recommended that certificates should not use RSA public keys shorter than 2048 bits after December 2013 and the CA/B forum imposes the same rule.
  • Missing OCSP URL — OCSP is one of the two available revocation mechanisms available to CAs to disable the certificate after it has been issued. As web-browser support for certificate revocation varies, non-EV certificates without an OCSP URL are effectively irrevocable in Firefox. Without the ability to revoke certificates, if the certificate were ever to be compromised — by criminals or government agencies — it could be used for up to five years. The Baseline Requirements do allow certificates to omit the OCSP URL if and only if they are used on "high traffic" websites and the website staples the OCSP response to the TLS handshake — none of the websites with missing OCSP URLs highlighted here did so.
  • SAN extension — the Baseline Requirements document discourages the use of the Subject Common Name field to contain the hostname for which the certificate is valid. Instead, the Subject Alternative Name extension should be used and it must contain at least one record. Additionally, any hostname in the Subject CN field must also be duplicated in the SAN extension — a multi-domain certificate intended for www1.example.com and www2.example.com must contain both in the SAN extension and at most one in the Subject CN (for backwards compatibility).
  • Validity Period — as of the effective date, the Baseline Requirements limit the maximum validity period of a certificate to 5 years (60 months). Whilst exceeding this validity period constraint isn't itself a security problem it slows downs the pace of change within the industry — with a shorter maximum validity period, browsers can rely on legacy behaviour disappearing and can remove insecure functionality more rapidly.

A short key warning for a 512-bit certificate in Google Chrome. This type of warning is proposed to be applied to certificates violating the maximum validity period.

Several large CAs have issued non-compliant certificates since July 2013, a year after the original deadline, including Symantec, Go Daddy, and Verizon Business.

  • Symantec — a BMW certificate issued by TC Trust Center (a Symantec company) is missing an OCSP URL and does not include a stapled OCSP response, making it irrevocable in Firefox. An SSL certificate used for online banking was issued by VeriSign on August 2nd 2013 without the required SAN extension.
  • Verizon Business — a certificate issued by Etisalat (a UAE-based telecoms provider which operates a Verizon Business signed sub-CA) for ADCO, an onshore oil drilling company, violates a number of Baseline Requirements: it has a short RSA key valid after 31st December 2013, it has no OCSP URL and it does not have the mandatory SAN extension. Etisalat has previously been associated with SSL interception. Cybertrust, operated directly by Verizon Business, has also issued more than its fair share of non-compliant certificates including certificates belonging to Target [Short Key, no OCSP URL], the US Dept. for Homeland Security [no SAN, no OCSP URL], and American Express [an EV certificate without an OCSP URL!]. A number of other sub-CAs signed by Verizon Business have issued non-compliant certificates including Microsoft [missing SAN, no OCSP URL] and Vodafone [missing SAN].
  • SwissSign — Nestlé, a customer of SwissSign with its own intermediate certificate, has issued non-compliant certificates including: those missing SAN records and OCSP URLs.
  • Go Daddy — a significant number of Go Daddy certificates exceed the maximum permitted validity period of 5 years. These certificates are likely "re-issued" (the meaning of which is debated by Google, see below) and otherwise do not obviously violate the Baseline Requirements. Go Daddy have proposed a modification to the Baseline Requirements to allow such re-issued certificates to be exempt from maximum validity period constraints.

Google Chrome, in the first quarter of 2014, will reject all certificates issued after the effective date, 1st July 2012, which violate the maximum validity period (60 months). A number of CAs have issued such certificates, often as part of a re-issuance process, which Google deems to be non-compliant with the Baseline Requirements.

In the September 2013 SSL Survey, using the criteria from the proposed Google Chrome patch, Netcraft found 3,243 certificates which will be considered invalid in Google Chrome as a result of this change. Go Daddy issued over three-quarters of these certificates (2,498) and Comodo also issued a significant number (606). The longest-lived non-compliant certificate issued by a member of the CA/B Forum and discovered by the SSL Survey has a validity period of over 82 months.

Furthermore, Google's technical enforcement is set to get tougher: Ryan Sleevi has stated that certificates with short public keys – that is, RSA public keys shorter than 2048 bits expiring after 31st December 2013 are “next up” on Google’s list. Google's proposal to use the original July 2012 date as a threshold for enforcement isn't popular with some of the CAs in the CA/B forum: GlobalSign and Comodo have argued that such technical constraints should only be enforced for certificates issued after the announcement.

Despite Google's aggressive stance, many of Google's own certificates did not comply with some of the Baseline Requirements: in the September 2013 Netcraft SSL survey, almost 500 Google certificates did not contain a URL to an OCSP responder or include a stapled OCSP response (making the certificates irrevocable in Firefox). Since the survey ran in mid-August, a large number of Google's certificates have been replaced and now contain an OCSP URL, but a few non-compliant certificates are still in use including one on Zagat.com. The Zagat.com certificate also has an incomplete SAN record (it does not contain the hostname from the Subject Common Name field).

中国云

[Read this article in English]

作为2012年度世界最大的贸易国,中国长期以来一直是一个劳动力和服务输出大国,即便是在信息技术领域,也和印度的差距越来越小。以亚马逊DigitalOcean为代表的欧美云计算服务提供商的不断发展壮大,预示着云计算基础设施会成为一种商品,而那些最廉价的提供商则会逐渐受到用户的青睐。

中国网民数量在2013年6月达到了5.91亿,超越了美国和欧洲。把互联网应用和其他内容放在目标用户所在的国家可以有效缩短访问所需时间并提高访问稳定性,所以日益增加的网民数量对本国的互联网基础设施建设提出了要求。

中国云主机市场的极速发展

在过去一年,在中国大陆境内直接连接到国际互联网的Web服务器数量增长了8.3%,且绝大多数增长都来自于云主机市场。在直接连接到国际互联网的Web服务器数量方面,阿里云是目前中国最大的云主机提供商。特别值得一提的是,阿里云拥有的直接连接到国际互联网的Web服务器数量在2013年9月达到了17,934,比去年同期增长了6倍。放眼全球,其增长量仅次于云计算巨头亚马逊

虽然中国的云计算基础设施建设尚处于起步阶段,但阿里云的未来还是很有希望的,因为它背靠着强大的阿里巴巴集团。阿里巴巴集团是中国拥有直接连接到国际互联网的Web服务器数量最多的公司,也是世界前30名之一,而且该集团旗下的淘宝网阿里巴巴交易市场等电子商务平台早已在中国家喻户晓。在阿里巴巴集团直接连接到国际互联网的Web服务器当中,有92%来自于阿里云。


Metric Sep 2012 Mar 2013 Jun 2013 Jul 2013 Aug 2013 Sep 2013
Hostnames 91,553 205,824 382,342 381,989 368,948 389,171
Active sites 23,596 55,654 119,089 116,835 146,310 150,089
Web-facing computers 2,670 8,038 15,931 16,846 17,670 17,934

Detailed view of Aliyun in terms of hostnames (web sites), active sites, and web-facing computers.

本土市场与中国防火长城

尽管中国云主机市场增长迅猛,但是Netcraft发现这些增长绝大多数都来自于面向中国本土市场的网站。把服务器尽可能安置在离终端用户较近的地方可以提高访问性能这一点在中国格外突出:可能是受到金盾工程(亦称中国防火长城)的影响,流入或流出中国大陆的网络数据有时候会很慢,不稳定,甚至被屏蔽。2013年9月,从阿里云连接到国际互联网的网站的域名有一半以上都在.cn顶级域下,有41%是.com,而在其他国家顶级域下的域名则非常少见。由此可推断,与亚马逊的全球化服务不同,阿里云目前还是比较局限于中国本土市场。

TLD share by domains of websites at Aliyun in September 2013


阻碍中国云服务全球的绊脚石

对于想吸引中国用户或访客的外国企业来说,使用中国境内的云主机是很有意义的,但是会遇到一些障碍。这些障碍也正解释了为什么中国云目前面向的主要还是本国用户且这种情况很可能还会持续一段时间:

  • 和最廉价的外国云主机提供商相比,中国云主机提供商在价格和操作系统等配置选择的多样性上都没有优势。以阿里云为例,除非选择2核或4核的CPU,否则按量付费的云主机不支持Windows操作系统,而且其价格也不比那些更成熟的竞争对手便宜。最廉价的按量付费的阿里云主机为单核CPU,512M内存,1Mbps带宽,价格每小时0.27元(约合0.04美金),几乎是亚马逊最便宜的云主机价格的两倍,而配置相近的DigitalOcean云主机的价格仅为每小时0.007美金。但是,由于定价模式的差异,包年包月的阿里云主机在某些情况下会比包年包月的亚马逊或DigitalOcean更便宜。
  • 从海外访问中国境内的网站有时不够顺畅 - 从英国发送到阿里云官方网站的数据包往返几乎要耗时半秒钟,而从美国访问的效果也没有好很多。在过去20天,有多达4%的来自荷兰的访问请求都以失败告终。

  • Performance of www.aliyun.com from a Netcraft performance collector located in the Netherlands


  • 很多中国主机服务提供商只支持中文。以阿里云为例,无论是官方网站、控制面板还是技术支持,中文都是其唯一的语言。不过,亚马逊云对中文的支持也几乎一样有限 - 只有首页有中文版。
  • 有些中国主机服务提供商只面向中国客户。例如:申请使用阿里云服务的用户必须要有一个中国的手机号来接收验证码以完成注册。按量付费的用户必须通过身份验证,而只有中国或个别亚太地区国家的公民或者中国的企业可以做这样的验证。想使用阿里云服务的客户还必须有一张与支付宝兼容的中国的银行卡。如果服务器需要通过域名访问,那么还必须在工信部备案,而这样的备案并不向外国企业开放。

这些障碍意味着中国的云主机服务目前还不太可能冲出中国,面向世界。但是,伴随着来自阿里云这样的本地提供商和微软、亚马逊这样的海外提供商之间的竞争,中国的云服务器数量很有可能会继续增长,来满足国内日益增多的需求。微软为了将其云主机服务打入中国市场,已经开始与中国的一家名为世纪互联的基础设施服务提供商进行合作,并且正在为中国市场定制极具竞争力的价格计划。也许通过这样的模式,其他外国企业(比如亚马逊)也可以将其云主机服务打入中国市场,不仅提供本地的数据中心,同时也争取在严格的监管环境下为中国客户提供支持。同样的,如果上述这些障碍能够在一定程度上得到解决,相信阿里云和其他中国云主机提供商也能够在国际大舞台上获得更多的市场份额。

Netcraft提供国际互联网基础设施方面的信息,包括主机服务提供商、网页技术等等。想了解更多关于云计算行业的信息,请访问 http://www.netcraft.com/internet-data-mining/


Building the Great Cloud of China

[中文版]

China, the world's largest trading nation in 2012, has long been a desirable location for outsourcing labour and services, even within the technology and IT sector where it is not far behind India. The growth of cloud computing providers in Europe and the United States — particularly Amazon and DigitalOcean — may foretell cloud computing infrastructure becoming a commodity and outsourced to the cheapest provider.

The ever-increasing number of internet users in China (591 million at the end of June 2013) requires the development of home-grown internet infrastructure: hosting web applications and other content within a target user's own country typically speeds up requests and improves reliability. The number of internet users in China is greater than either the United States or Europe.

Stratospheric growth in Chinese cloud hosting

Although the number of web-facing computers in China has grown by 8.3% over the last year — the majority of this growth has occurred within the cloud hosting market. Aliyun (云, pronounced 'yun', is the Chinese word for cloud) is the largest cloud computing provider in China in terms of the number of web-facing computers, and remarkably, Aliyun now has six times more web-facing computers than it did a year ago, reaching a total of 17,934 in September 2013. Worldwide, only the cloud computing giant Amazon gained a greater number of web-facing computers.

Although China's cloud computing infrastructure is still in its infancy, Aliyun's future looks particularly promising, as it is owned by the Alibaba Group. This group is the largest hosting provider in China, features within the top 30 hosting providers worldwide, and has already established a strong internet presence with its better known e-commerce platforms, Taobao and Alibaba.com. Aliyun now makes up almost 92% of the web-facing computers at Alibaba Group.

Metric Sep 2012 Mar 2013 Jun 2013 Jul 2013 Aug 2013 Sep 2013
Hostnames 91,553 205,824 382,342 381,989 368,948 389,171
Active sites 23,596 55,654 119,089 116,835 146,310 150,089
Web-facing computers 2,670 8,038 15,931 16,846 17,670 17,934

Detailed view of Aliyun in terms of hostnames (web sites), active sites, and web-facing computers.

Indigenous market and the Great Firewall of China

Despite the strong growth of the Chinese cloud hosting market, most of the growth seen by Netcraft is hosting sites aimed at the Chinese market. Hosting content as close to the end-users as possible increases the performance of the web site, and this effect is particularly prominent in China: internet traffic crossing the border can sometimes appear to be slow, unstable, or even blocked, perhaps as a side-effect of blocks enforced by the Golden Shield Project (also known as the Great Firewall of China). In September 2013, more than half of the domains of websites hosted at Aliyun were in the .cn TLD, around 41% in .com, whilst domains in other ccTLDs appeared to be very rare. Unlike Amazon's global reach, Aliyun's reach appears to be limited to the local market — at least for the time being.

TLD share by domains of websites at Aliyun in September 2013


Obstacles holding back the Chinese cloud

Using cloud hosting in China could make sense for non-Chinese companies looking to increase their presence in China; however, a number of obstacles remain. These explain why the Chinese cloud is still mostly indigenous, and is likely to remain so for some time:

  • Neither the pricing models nor the variety or operating systems are as attractive as those offered by the cheapest non-Chinese cloud hosting companies. Taking Aliyun as an example, its on-demand instances do not support Windows operating systems unless you opt for a 2-core or 4-core CPU, and they are not significantly cheaper than its more established competitors. The cheapest on-demand option at Aliyun is ¥0.27 ($0.04) per hour which buys you a single core, 512MB of RAM, and a 1Mbps internet connection. This is almost twice the price of Amazon's cheapest option and a comparable DigitalOcean instance can be had for just $0.007 per hour. However, as pricing models vary, reserved instances at Aliyun can be cheaper in some circumstances.
  • Internet connectivity from outside China can be patchy — packets sent to www.aliyun.com from the United Kingdom take almost half a second to make the journey and back again, and the performance in the United States is not much better. More than 4% of requests to www.aliyun.com from the Netherlands failed during the past 20 days.

  • Performance of www.aliyun.com from a Netcraft performance collector located in the Netherlands


  • Many Chinese hosting services are only available in the Chinese language. This is the only language available for Aliyun's brochure website, control panel, and technical support. However, Amazon's support for the Chinese language is almost as limited — a single marketing site appears to be the sole Chinese-language site for AWS.
  • Some Chinese hosting companies only accept business from Chinese customers. For example, Aliyun's customers are required to have a Chinese mobile phone number in order to receive a verification code to complete the signup process. Customers wishing to buy an on-demand instance at Aliyun must go through an identity verification process, which requires the registrant to be a national of China or one of a few other Asia-Pacific countries, or to represent a Chinese company. Customers must also hold a credit or debit card issued by a Chinese bank compatible with Alipay. Customers must also register with the Chinese Ministry of Industry and Information Technology if they wish to associate a domain name with an Aliyun cloud server, but such registration is currently unavailable to foreign enterprises.

The current obstacles suggest that the cloud is unlikely to be outsourced to China yet. However, the availability of cloud computers in China is likely to increase to match its rapidly increasing local demand with competition both from local providers like Aliyun and overseas players like Microsoft and Amazon. Microsoft has collaborated with a partner company in China, 21Vianet, in order to bring its Cloud to China, and is making competitive price plans customised for the Chinese market. Perhaps by following this model, other non-Chinese companies such as Amazon could enter the Chinese market, providing local data centres and support to Chinese-speaking customers within the stricter regulatory environment. Equally, if some red tape were cut and network connectivity improved, Aliyun and other Chinese cloud providers could be poised to take a larger share of the global cloud computing market.

Netcraft provides information on the internet's infrastructure, including the hosting industry and web content technologies. For information on the cloud computing industry, please see http://www.netcraft.com/internet-data-mining/.