In the June 2013 survey we received responses from 672,985,183 sites, 148k more than last month.
Both Microsoft and Google grew slightly this month, gaining 0.5 percentage points of market share. Microsoft's web server, IIS, now serves 17.22% of the world's websites, down from a historic high of 37% which it reached in October 2007. Microsoft IIS's market share amongst secure websites (HTTPS) is significantly higher: it serves 39% of the secure websites found by Netcraft and is in 2nd place behind Apache. Apache's lead over Microsoft in the secure website market is only slight: it is ahead by just two percentage points and doesn't hold an absolute majority as it does for non-secure websites (HTTP).
Despite its market share dipping slightly, Apache is still significantly ahead of its position just two months ago due to Go Daddy's switch last month to Apache Traffic Server. Within the Million Busiest Sites, Apache bucked its recent downward trend this month: 7,300 more websites than last month are using Apache, including DigiCert's website which switched from nginx to Apache 2.4.5 (2.4.4 is the latest stable release).
nginx's growth within the Million Busiest Sites remains strong, 5,400 more busy websites now use the web server since last month's survey including The Verge which switched from Apache. Across all web sites, however, nginx lost almost 1% of market share and 6.4M websites caused by a large network of websites at namecheap.com failing to respond during the survey.
In early May 2013, nginx released a patch for a high severity security vulnerability which could allow an attacker to execute arbitrary code. Several attacks exploiting the vulnerability in the chunked transfer size calculation have been demonstrated including a proof of concept and an automated metasploit module. Almost 2M websites — or around 2% of all websites using nginx — presented a server banner corresponding to a vulnerable version (1.3.9+ and 1.4.0). The vast majority of nginx websites do not report the version in the server banner; however, the two most popular versions reported are 1.2.1 (released in June 2012) and 1.0.15 (released in April 2012) which do not have this vulnerability but may have others if left unpatched.
nginx is the most commonly used web server at Amazon: it is used on 41% of the 12M websites hosted using EC2 or S3. Last month Netcraft reported Amazon had 158k web-facing computers and has been the largest hosting provider by the number of web-facing computers since September 2012. After nginx, Apache is the next most common web server, 24.7% of websites use it, followed by Microsoft with 14%. Only 1% presented the AmazonS3 server banner, which can be used to host entire static websites in addition to simply static files.
Developer May 2013 Percent June 2013 Percent Change Apache 359,441,468 53.42% 358,974,045 53.34% -0.08 Microsoft 112,303,412 16.69% 115,920,681 17.22% 0.53 nginx 104,411,087 15.52% 97,991,191 14.56% -0.96 23,029,260 3.42% 26,036,616 3.87% 0.45
Rank Performance Graph OS Outage
DNS Connect First
Total 1 Qube Managed Services Linux 0:00:00 0.006 0.099 0.045 0.091 0.091 2 Datapipe FreeBSD 0:00:00 0.009 0.073 0.016 0.033 0.051 3 ServerStack Linux 0:00:00 0.009 0.077 0.066 0.134 0.134 4 Bigstep Linux 0:00:00 0.009 0.269 0.071 0.143 0.143 5 iWeb Linux 0:00:00 0.009 0.121 0.073 0.144 0.144 6 www.dinahosting.com Linux 0:00:00 0.012 0.178 0.098 0.198 0.198 7 XILO Communications Ltd. Linux 0:00:00 0.015 0.218 0.076 0.361 0.517 8 Swishmail FreeBSD 0:00:00 0.018 0.110 0.062 0.124 0.226 9 INetU Windows Server 2008 0:00:00 0.018 0.130 0.072 0.236 0.456 10 Virtual Internet Linux 0:00:00 0.018 0.165 0.074 0.324 0.453
Qube Managed Services had the most reliable hosting company site in May, with only 2 failed requests. Qube specialises in providing managed hosting from three data centres in London, New York and Zurich. Qube was founded in 2001 and provides services to a number of notable clients, including Betfair (a large betting exchange) and blinkbox (a video streaming service from Tesco in the UK). Qube has appeared in the top 10 over twenty times since Netcraft began monitoring it in March 2010 and has now ranked in 1st place four times.
Datapipe and ServerStack placed 2nd and 3rd, both narrowly missing the top spot by a single failed request. Datapipe had the lowest average connection time out of all the top 10 sites, which breaks the tie with ServerStack in its favour. Datapipe has continued to maintain its 100% uptime record having recently passed the 100% uptime over 7 years milestone despite some of its nine data centres being in the path of hurricanes, typhoons, and a snowstorm. Serverstack has now been monitored by Netcraft for seven months and has already appeared in the top 10 four times. The company's 100% uptime SLA offers 5% credit for every half hour of sustained unscheduled downtime.
All but three of May's top 10 most reliable hosting companies hosted their own sites on Linux, including Qube in 1st place, ServerStack in 3rd place and Bigstep in 4th place, which made its debut entry in the table last month. FreeBSD is used by 2nd place Datapipe and last month's winner Swishmail (this month in 8th place). INetU was the only hosting company in the top 10 to host its site on Windows Server 2008.
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.
Rank Performance Graph OS Outage
DNS Connect First
Total 1 ocsp.starfieldtech.com Linux 0:00:00 0.013 0.111 0.023 0.043 0.043 2 ocsp.trendmicro.com/tmca Citrix Netscaler 0:00:00 0.019 0.043 0.099 0.200 0.200 3 ocsp.entrust.net Linux 0:00:00 0.022 0.251 0.014 0.249 0.249 4 ocsp.godaddy.com Linux 0:00:00 0.022 0.164 0.021 0.041 0.041 5 ocsp.digicert.com Linux 0:00:00 0.022 0.027 0.026 0.051 0.051 6 ocsp.quovadisglobal.com Windows Server 2003 0:00:00 0.032 0.021 0.116 0.222 0.222 7 ocsp.verisign.com Citrix Netscaler 0:00:00 0.038 0.050 0.084 0.168 0.168 8 evsecure-ocsp.verisign.com Citrix Netscaler 0:00:00 0.041 0.239 0.085 0.168 0.168 9 ocsp.thawte.com Citrix Netscaler 0:00:00 0.044 0.041 0.083 0.165 0.165 10 ocsp.startssl.com/sub/class4/server/ca Linux 0:00:00 0.047 0.086 0.011 0.041 0.041
Starfield Technologies had the most reliable OCSP responder during April, failing to respond to only 4 of Netcraft's OCSP requests. Starfield also had the most reliable responder in March, but showed a slight improvement to its average connection times in April. Starfield was founded as the technology and research branch of Go Daddy in 2003, and Go Daddy customers can choose to have their SSL certificates issued by either Starfield or Go Daddy.
Trend Micro had the second most reliable OCSP responder, which failed to respond to only 6 requests. However, this could be one of the survey's least busy responders: Netcraft's April 2013 SSL Survey discovered only 113 valid SSL certificates issued by Trend Micro, all of which are organisation validated. 29 of these certificates are used by a single organisation, Florida Hospital.
StartCom (which operates StartSSL) once again exhibited the fastest connection times, taking only a hundredth of a second to establish a TCP connection for one of its OCSP URLs. However, its reliability was only just good enough to make it into the top ten — in total, 15 requests to http://ocsp.startssl.com/sub/class4/server/ca failed during April.
Linux is the most popular choice of operating system on which to run an OCSP responder, and it certainly seems to perform well with regard to connection times: all of the top 25 fastest OCSP responders used Linux in April. In terms of failed requests, though, the distribution of Citrix Netscaler appliances is skewed towards the more reliable end of the spectrum — of the five responders that were using Netscaler, four of them feature in the top ten. QuoVadis's OCSP responder, which was sixth most reliable in April, is one of only two responders that ran on Windows.
On April 24, nginx 1.4.0 stable was released, incorporating several new features that had previously only been released in development branches of the web server. One of the most important performance features is that nginx now support OCSP stapling. This feature is designed to improve performance by allowing secure websites to "staple" a cached OCSP response to the TLS handshake, removing the need for the client browser to make a second, separate connection to the certificate authority's OCSP responder.
The Online Certificate Status Protocol (OCSP) is an alternative method to Certificate Revocation Lists (CRLs) for obtaining the revocation status of an individual SSL certificate. Fast and reliable OCSP responders are essential for both Certificate Authorities (CAs) and their customers — a slow OCSP response will introduce an additional delay before many browsers can start sending and receiving encrypted traffic over an HTTPS connection.
Despite the inconsistent treatment of certificate revocation by browsers, providing reliable revocation information is an integral part of operating a trustworthy certificate authority (CA) and a well-accepted requirement of Mozilla's CA root program. However, there are presently thousands of certificates in use which are irrevocable in some major browsers, and hundreds in those browsers which do everything right.
Without the ability to revoke a certificate, a CA has no control over whether a certificate is accepted by browsers or relied upon for secure communication after its issuance and before its expiry. A compromised private key and certificate in the hands of an attacker could be devastating: he would be able to use the private key to decrypt some intercepted SSL-secured traffic and the certificate to impersonate the targeted site. Even if the CA becomes aware of the problem, they can do nothing about it directly without having to rely on the browser vendor's support. CAs use two main technologies for browsers to check whether a particular certificate has been revoked: using the Online Certificate Status Protocol (OCSP) or looking up the certificate in a Certificate Revocation List (CRL). OCSP provides revocation information about an individual certificate from an issuing CA, whereas CRLs provide a list of revoked certificates and may be received by clients less frequently.
Assessing browser support for the two forms of revocation is complicated by Google Chrome's varying behaviour, depending on the platform, browser settings, and its use of pre-aggregated crlsets which contain revocation information for a limited selection of certificate authorities. Firefox does not automatically download CRLs for non-EV certificates so, by default, must rely on OCSP alone. Both Internet Explorer and Opera are more secure in this context: they support OCSP and CRLs and make suitable checks for all types of certificate. Safari does not make revocation checks at all by default for non-EV certificates and the mobile version does not provide the option to do so. For most Safari users, whether or not a certificate is irrevocable is immaterial — Safari does not check for revocation by default.
Excerpt from Netcraft's site report for https://www.bancagenerali.it showing the lack of any revocation method available.
Netcraft has found hundreds of certificates trusted by major browsers which are effectively irrevocable; that is they do not contain valid entries in the crlDistributionPoints X509 extension or OCSP URLs in the AuthorityInformationAccess extension. There may be appropriate CRLs or OCSP responders available, but there is no standard automated means to discover them. Without these two extensions, there is some chance a browser will use a cached CRL (downloaded after visiting another site using the same intermediate certificate) and have access to revocation information not otherwise available. It is easy, however, to envision many scenarios where this fortunate event hasn't occurred before a person visits a site with a revoked certificate.
The CA/B forum — an organisation of both CAs and browsers — publishes a set of Baseline Requirements (BR), which allow a CA to rely on OCSP stapling for "high-traffic" FQDNs and omit OCSP URLs from the certificate. However, currently there is not a widely supported method for enforcing the use of OCSP stapling. The draft TLS Security Policy extension can contain a must-staple directive, which, if present, will indicate to clients to reject any connection without a stapled OCSP response.
In Netcraft's May 2013 SSL survey, more than 300,000 certificates did not contain an OCSP responder URL and are thus irrevocable in Firefox (except for a handful of hard-coded OCSP responder URLs); of these, almost 9,000 were issued this year. Around 800 did not contain URLs for either revocation method, making them effectively irrevocable.
The table below shows some example certificates which are missing some or all of the URLs pointing to revocation methods.
Example certificate Site rank Certificate Authority OCSP servers Certificate Revocation Lists OCSP Stapling enabled Self-declared BR compliance according to responses to Mozilla fsgateway.aexp.com American Express (Verizon Business) No No No Not yet compliant www.bancagenerali.it 28,225 I.T. Telecom (Verizon Business) No No No Not yet compliant *.malaga.es FNMT No No No N/A accounts.google.com 7 Google Internet Authority (Symantec) No Yes No Compliant login.skype.com 1,804 Microsoft (Verizon Business) No Yes No Not yet compliant query.rapidssl.com 1,280,616 Symantec No Yes No Compliant www.faa.gov 498,030 Verizon Business No Yes No Not yet compliant www.creditmutuel.de KEYNECTIS No Yes No Compliant *.mygrants.gov.my AlphaSSL (GlobalSign) No Yes No Partially compliant
There are a number of certificate authorities which have issued such certificates, including the following:
- An American Express certificate, issued by their own certificate authority, does not contain URLs for either revocation method nor does it staple an OCSP response, making it totally irrevocable. American Express's certificate authority eventually chains up to GTE CyberTrust (now Verizon Business). This certificate was issued before the effective date of the CA/B forum's Baseline Requirements.
- Google Internet Authority, a subordinate CA of Equifax (now Symantec), does not include OCSP responder URLs in any of its certificates making the certificates effectively irrevocable in Firefox except by action by the browser vendor. Even if Google were to use OCSP stapling (which it does not appear to do — at least on some popular sites) people using Firefox would be no better off as support by default is still in the pipeline. The lack of OCSP URLs may be a conscious decision by Google to reduce the performance penalty of using SSL. The risk posed by not performing this check is not theoretical as one of Google's CRLs contains 7 serial numbers for certificates which were revoked for 'Key Compromise', an event which can't be dealt with directly by Google for users of Firefox.
- A number of other certificate authorities have issued certificates without OCSP responder URLs this year, including Symantec, Verizon Business, GlobalSign, Microsoft, and KEYNECTIS. The original Baseline Requirements document — effective from 1 July 2012 — stated that there MUST be at least one OCSP URL in the AuthorityInformationAccess extension.
- Several recently-issued irrevocable certificates violate other Baseline Requirements. For example many certificates also have RSA keys shorter than 2048-bits expiring beyond the end of this year — the CA will not be able to revoke them effectively on 1st January 2014 as is required. I.T. Telecom (which is a subordinate CA of Verizon Business) and FMNT (the Spanish Royal Mint) are the worst offenders, having issued totally irrevocable certificates with short public keys. Some major CAs have also signed certificates with short public keys and only CRL revocation available including Symantec and Verizon Business.
None of the example certificates mentioned above responded with a valid OCSP response stapled, so the limited exception allowed in the Baseline Requirements for high-traffic FQDNs isn't applicable.
Whilst the majority of certificates issued by major CAs are revocable in line with the Baseline Requirements, browser vendors could consider enforcing the most security-critical requirements in the browser itself, raising the bar for all certificate authorities. Browser vendors are somewhat limited in the available methods to sanction or remove their trust in widely used CAs: straightforward revocation of intermediates or root certificates runs the risk of disabling a large proportion of secure websites leading users to question not the CAs, but the browser software and the web site they are visiting.
23/05/2013: Edited to correct attribution of Microsoft's CA to Verizon Business.
In September 2012 Netcraft reported that Amazon had become the largest hosting company in the world based on the number of web-facing computers. In the last eight months, the e-commerce company's tally of web-facing computers has grown by more than a third, reaching 158k. The number of websites hosted on these computers has also increased, from 6.8M in September 2012 to 11.6M in May 2013, a 71% increase.
Although Amazon’s main business is still online retail, Amazon Web Services (AWS), its cloud computing division, has been growing in significance. In Amazon's first quarter of 2013 the Other category (which still includes AWS along with other non-retail activity) was just under 5.0% of its revenue, up from 3.2% at the same point in 2011. The first publicly available AWS service was launched in 2004, but it was not until 2006 that Amazon launched its two core services S3 (data storage) and EC2 (per-hour rental of virtual computer instances). Since then, Amazon has been increasing the number of services provided: in 2012 alone, 159 new services and features were released.
Including its retail infrastructure, the number of web-facing computers at Amazon has grown more than thirty-fold in four years: in May 2009, Netcraft found 4,600 Amazon-controlled web-facing computers; in May 2013, Netcraft found 158k web-facing computers on 164k IP addresses. Netcraft estimates the number of computers behind a group of IP addresses by using a variety of heuristics based on the TCP/IP characteristics seen in the HTTP responses gathered. Hosted on those computers, there are more than 11.6M websites (or hostnames) which corresponds to 2.1M websites with unique content (active sites). Despite being the largest hosting provider by number of web-facing computers, it is dwarfed by Go Daddy, the largest hosting provider when considering the number of websites hosted. Go Daddy has 37M websites on just 23k web-facing computers: the high ratio of websites to web-facing computers may be indicative of Go Daddy's role as a registrar, for which it has a large network of holding pages, and its inexpensive shared hosting platform.
EC2 - Elastic Compute Cloud
EC2, provides on-demand virtual-computer instances billed per hour and is currently available from all nine AWS regions. Each region may correspond to multiple physical data centres which are structured into "Availability Zones". The two largest regions, US East (Northern Virginia) and EU West (Ireland), account for more than three-quarters of all EC2 usage as measured by Netcraft. Sydney, the newest AWS region, now accounts for just under 1% of all measured web-facing computers using AWS, having almost tripled in size in the past four months. In total, more than 156k instances power at least one hostname on 3M domains across the internet.
Launched in 2011, the GovCloud (US) region is specifically intended for more sensitive applications that require additional security and compliance with US regulations. As of May 2013, Netcraft found just 27 web-facing computers within the government cloud, some of which power www.grdregistry.org and www.govdashboard.com. Given its intended role, it would not be surprising if a large proportion of the computers used in the region are not web-facing.
Metric (EC2 Total) February 2013 March 2013 April 2013 May 2013 Growth (4 month) Web-facing Computers/Instances 141,960 145,648 152,041 156,225 10% IP Addresses 144,625 148,837 155,712 160,884 11.2% Domains 2,788,685 2,810,906 2,996,147 3,061,178 9.8% Hostnames 9,489,496 9,938,480 10,649,545 10,925,661 15.1%
Many uses of EC2 such as batch data-processing will not be directly measurably over the internet: Netcraft measures publicly visible computers with corresponding DNS entries and which respond to HTTP requests. Netcraft's Web Server Survey is run at Amazon from the Northern Virginia region, so the region may be over-reported due to services like latency based multi region routing which provide differing responses depending on topological location.
Geographic distribution of computers per EC2 region in May 2013
Data Centre (EC2 - Web Facing Computers) February 2013 March 2013 April 2013 May 2013 Growth (4 month) Asia Pacific (Singapore) 6,576 6,805 6,998 7,290 10.9% Asia Pacific (Sydney) 499 739 1,129 1,427 186% Asia Pacific (Tokyo) 7,342 7,595 8,065 8,601 17.1% EU West (Ireland) 23,778 24,635 25,326 25,942 9.1% South America (Sao Paulo) 2,115 2,263 2,396 2,655 25.6% US East (Northern Virginia) 87,094 88,543 92,426 93,537 7.4% US West (Northern California) 9,325 9,478 9,715 9,695 4% US West (Oregon) 5,217 5,573 5,965 7,051 35.2% GovCloud (Oregon) 14 17 21 27 92.9%
S3 - Simple Storage Service
S3 provides an online file storage service which can be managed programmatically via Amazon's API. Files are logically grouped into containers called buckets which can be made public and accessible over HTTP but default to being private. As with EC2, Netcraft cannot track private use of S3 but is able to survey websites using S3 publicly to serve static files and even entire websites.
Metric (S3 Total) February 2013 March 2013 April 2013 May 2013 Growth (4 month) Domains 41,782 42,561 45,721 48,636 16.4% Hostnames 124,454 127,370 132,962 138,588 11.4%
In May 2013, a total of 139k hostnames were found to be hosted directly on S3, either using a subdomain of s3.amazonaws.com or using a custom CNAME pointing to S3. Of these, 24.7k hostnames, or over 18.5k domains, point to an S3 bucket configured to serve an entire website, as does mediahackers.org. Many more websites are not hosted entirely on S3, but make use of the service to serve static files such as images, stylesheets, or file downloads.
One of the most widely referenced S3 hostnames is used for twitter badges bucket, which was once a common method to display twitter icons on a third-party website. Tumblr, a popular blogging platform recently acquired by Yahoo!, also makes use of S3 to host static media.
CloudFront is a Content Delivery Network which can be used to serve both dynamic and static content from 28 edge locations which are topologically closer to a site's visitors. Caching content reduces the bandwidth and performance requirements on the website's own servers and, by being topologically close to visitors, the latency associated with each HTTP request can be improved.
In the May 2013 survey, more than 63k hostnames were served via CloudFront, more than 60% of which point to an S3 bucket. Amazon uses CloudFront on its own websites, including imdb.com, and also uses it for serving images on Amazon.com. Other than Amazon itself, CloudFront users include: the Toronto Star, a Canadian newspaper, and Pirifrom, the makers of utility program CCleaner, are two of the most visited sites using CloudFront amongst users of the Netcraft Toolbar.
Metric (CloudFront Total) February 2013 March 2013 April 2013 May 2013 Growth (4 month) Domains 22,920 24,079 25,264 26,221 14.4% Hostnames 55,578 57,817 60,475 63,203 13.7%
The number of CloudFront-dedicated IP addresses and computers cannot be easily measured as different results are obtained depending on the location of the request.
Route 53, is a managed Domain Name System (DNS) hosting service. Route 53, named for the TCP and UDP port used for the protocol, hosts DNS records which map from human-readable hostnames to IP addresses. Integrated with the rest of AWS, it allows programmatic access to change DNS records in response to changes elsewhere in a customer's infrastructure. As with CloudFront, Amazon have servers providing this service in edge locations outside of its 9 EC2 regions; Route 53 is available from 28 separate locations.
Metric (Route 53 Total) February 2013 March 2013 April 2013 May 2013 Growth (4 month) Domains 136,698 146,635 161,619 169,111 23.7% Hostnames 3,493,986 3,662,195 3,831,910 4,068,053 16.4%
Over the past four months there has been a steady growth in the number of websites using Route 53 to host their DNS records: it now serves DNS records for 169k domains. Busy sites making use of this service include pinterest.com, a social photo-sharing website which is a heavy user of Amazon's infrastructure; MediaFire, a file uploading and sharing service; and ow.ly a URL shortener.
Heroku is Platform as a Service (PaaS) provider owned by Salesforce. Whilst not operated by Amazon, it makes heavy use of AWS services, especially EC2. Heroku provides an abstracted managed environment for web developers to deploy applications in a number of different languages. In May 2013, Heroku was serving 70K domains directly (not behind a CDN) across 4,786 computers.
Metric (Heroku total) April 2013 May 2013 Growth (2 month) Computers 4,293 4,786 11.5% IP Addresses 4,408 4,972 12.8% Domains 65,821 69,781 6% Hostnames 1,094,578 1,102,663 0.7%
Heroku, as demonstrated in the results from Netcraft's survey, has been available almost exclusively from the Northern Virginia EC2 region. In April, Heroku announced availability of its service in Europe from the AWS EU West region based in Ireland. Only a limited number of Heroku customers have had access to this region during a private beta phase which explains the currently low uptake: only 1% of the computers attributed to Heroku were in the region.
IP Addresses April 2013 May 2013 US East (Northern Virginia) 4,374 4,915 EU West (Ireland) 33 56
Netcraft provides information on the Internet infrastructure, including the hosting industry, and web content technologies. For information on the cloud computing industry including Microsoft Azure, Rackspace Cloud, and Google App Engine, please contact email@example.com.
Certificate revocation is intended to convey a complete withdrawal of trust in an SSL certificate and thereby protect the people using a site against fraud, eavesdropping, and theft. However, some contemporary browsers handle certificate revocation so carelessly that the most frequent users of a site and even its administrators can continue using an revoked certificate for weeks or months without knowing anything is amiss. Recently, this situation was clearly illustrated when a busy e-commerce site was still using an intermediate certificate more than a week after its revocation.
SSL Certificates are used to secure communication between browsers and websites by providing a key with which to encrypt the traffic and by providing third-party verification of the identity of the certificate owner. There are varying levels of verification a third-party Certificate Authority (CA) may carry out, ranging from just confirming control of the domain name (Domain Validation [DV]) to more extensive identity checks (Extended Validation [EV]).
However, an SSL certificate — or any of the certificates which form a chain from the server's certificate to a trusted root installed in the browser or operating system — may need to be revoked. A certificate should be revoked when it has had its private key compromised; the owner of the certificate no longer controls the domain for which it was issued; or the certificate was mistakenly signed. An attacker with access to an un-revoked certificate who also has access to the certificate's private key can perform a man-in-the-middle (MITM) attack by presenting the certificate to unsuspecting users whose browsers will behave as if they were connecting to a legitimate site.
There are two main technologies for browsers to check the revocation status of a particular certificate: using the Online Certificate Status Protocol (OCSP) or looking up the certificate in a Certificate Revocation List (CRL). OCSP provides revocation information about an individual certificate from an issuing CA, whereas CRLs provide a list of revoked certificates and may be received by clients less frequently. Browser support for the two forms of revocation varies from no checking at all to the use of both methods where necessary.
On 30th April 2013 an intermediate certificate issued to Network Associates — which forms part of the chain from an individual certificate back to a trusted root — was revoked by RSA. The intermediate certificate was used to sign multiple McAfee SSL certificates including one for a busy e-commerce website, www.mcafeestore.com. Its revocation should have prevented access to all of the websites using the intermediate including the online store. However, more than a week later nobody had noticed: no tweets or news articles appeared and the certificate was still in place.
The certificate chain for mcafeestore.com, before it was replaced. The highlighted certificate, NAI SSL CA v1, was revoked on 30th April 2013
The intermediate certificate was revoked by RSA by adding its serial number, 54:99:05:bd:ca:2a:ad:e3:82:21:95:d6:aa:ee:b6:5a, to the corresponding CRL. None of the certificates in the chain provide a URL for OCSP, so using the CRL is the only option available. After the CRL was published, browsers should display an error message and prevent access to the website. The reality is somewhat different, however.
Business as usual in Firefox
Firefox does not download CRLs for websites which use the most popular types of SSL certificate (all types of certificate except EV which is usually displayed with a green bar). Without downloading the CRL, Firefox is happy to carry on as usual; letting people visit the website and transfer sensitive personal information relying on a certificate that is no longer valid. In any case even if OCSP were available, by default Firefox will only check the validity of the server's certificate and not attempt to check the entire chain of certificates (again, except for EV certificates).
No warnings for mobile users either on Android or iOS
Mobile browsing now makes up a significant proportion of internet use. Neither Google Chrome on Android nor Safari on iOS present a warning to the user even after being reset. Safari on iOS does not make revocation checks at all except for Extended Validation certificates and did not make requests for the CRL which would have triggered the revocation error message.
Google Chrome: [left to right] default settings, revocation checks enabled on Windows, and revocation checks enabled on Linux
Google Chrome, by default, does not make standard revocation checks for non-EV certificates. Google does aggregate a limited number of CRLs and distributes this via its update mechanism but, at least currently, it does not list the certificate in question or indeed any of the other certificates revoked in the same CRL. For the majority of Chrome users with the default settings, as with Firefox, nothing will appear to be amiss.
For the security conscious, Google Chrome does have the option to enable proper revocation checks, but in this case the end result depends on the platform. On Windows, Google Chrome can make use of Microsoft's CryptoAPI to fetch the CRL and it correctly prevents access to the site. However, RSA's CRL is not delivered in the conventional way: instead of providing the CRL in a binary format, it is encoded into a text-based format which is not the accepted standard. Mozilla's NSS — which is used by Firefox on all platforms and by Google Chrome on Linux — does not support the format. On Linux, Google Chrome does make a request for the CRL but cannot process the response and instead carries on as normal.
Warning to potential customers when visiting the store at https://www.mcafeestore.com
Microsoft's web browser, Internet Explorer is one of the most secure browsers in this context. It fetches revocation information (with a preference for OCSP, but will fallback to CRLs) for the server's certificate and the rest of the certificate chain and, as a consequence of the revocation check, it prevents the user from making their purchase on www.mcafeestore.com.
Opera preventing access to the website
Along with Internet Explorer, Opera is secure by default: it prevents access to the webpage. Opera checks the entirety of the certificate chain using either OCSP or CRLs where appropriate.
However, even with the most secure browser, the most frequent users of a secure website may be able to continue using a website for weeks or months despite one of the certificates in the chain of trust having been revoked. The CRL used in this case can be cached for up to 6 months, leaving frequent users, who will have a cached copy of the CRL, in the dark about the revocation. Going by previous copies of the CRL, the CRL may have last been generated in January 2013 and valid until July 2013. If that is the case and you have visited any website using the same intermediate certificate your browser will not display any warnings and will behave as if the certificate has not been revoked. However, you need not have visited mcafeestore.com before to have a cached CRL; there were 14 other websites with the same intermediate certificate in Netcraft's latest SSL survey.
As long as six months sounds to miss out on important revocation information, browser vendors in control of the list of trusted CAs allow CRLs to have 12-month validity periods when destined for intermediate certificates. CRLs covering individual, or subscriber, certificates are required to be valid for at most 10 days. By its very nature access to the private key corresponding to an intermediate certificate is more useful to an attacker: he can use the private key to sign a certificate for any website he so chooses rather than having access to just a single site. Browsers do have the ability to distrust certificates if they become aware of the compromise, but they may depend on slow update mechanisms to update the trusted set of certificates.
Whilst it may be expensive for an online store to be using a certificate that should not be valid, the consequences for governmental or banking websites could be more severe. If the certificate, or one of the certificates in the chain, were revoked due to a key compromise and there is an active attacker exploiting the lack of revocation checking in modern browsers, the public could be at risk for an extended period of time. The state of revocation amongst modern browsers is sufficiently fragmented to ensure that the entire concept of revocation is on shaky ground — without consistent behaviour and timely updates, if or when the certificate is finally blocked it is too late.
Netcraft waited until the certificate was replaced before publishing this article.