Phishers using CloudFlare for SSL

Some Content Delivery Networks (CDNs) enable fraudsters to deploy phishing attacks with valid SSL certificates. Not only does this make the fraudulent sites appear more credible, but they also benefit from the fast response times provided by the CDN.

A Turkish phishing site using CloudFlare (site has since been taken down)

The phishing site on odemerkezi.com is targeted at Turkcell customers — visitors to the phishing site are asked for their phone number, bank name, credit card details, and password. As CloudFlare's SSL feature is only available on paid accounts (which start at $20/month), the fraudster may have used an early victim's credit card to purchase the Pro plan.

Netcraft is currently blocking hundreds of phishing attacks which use CloudFlare's content delivery network, including some which use CloudFlare-provided SSL certificates. So far this year, Netcraft has blocked more than 2,000 phishing attacks using Cloudflare's infrastructure, of which approaching 200 used SSL.

CloudFlare's SSL certificates make use of the Subject Alternative Name (SAN) extension, which allows an edge node to use a single certificate for multiple domains. In the case of www.odemerkezi.com, the edge node presented a certificate which had a common name (CN) of "ssl2796.cloudflare.com", but also included the odemerkezi.com domain along with the domains of many other CloudFlare customers.

An SSL certificate used by a CloudFlare edge node server. It is valid for multiple domains belonging to its customers.

The multi-domain SSL certificates used by CloudFlare edge nodes are issued by GlobalSign. Rather than using Server Name Identification (SNI) — which would allow an individual certificate to be used for each website on a single IP address — CloudFlare uses GlobalSign's Cloud product to work around a lack of support for SNI in Internet Explorer on Windows XP and some mobile browsers. The two companies announced their partnership less than a year ago, and GlobalSign's own website uses CloudFlare, as do its OCSP and CRL services.

Some of the SSL phishing sites on CloudFlare that have been blocked by Netcraft have used deceptive domain names, such as paypal-germany.de.com, paypal-kundensicherheit.net and paypal-verifikation.com. Last month, a similarly deceptive domain name and SSL certificate issued by Network Solutions was used in a phishing attack against customers of Chase Bank.

Domain registrars and certificate authorities can reduce the likelihood of new domains and certificates being used for fraudulent activities. Netcraft's Domain Registration Risk service identifies domains which are deceptively similar to legitimate websites run by banks and other institutions that are commonly targeted by phishing attackers.

October 2013 Web Server Survey

In the October 2013 survey we received responses from 767,234,152 sites, an increase of 28.2M.

Apache experienced another significant loss, 1.8M hostnames, and saw its market share drop to 45% — the lowest it has been for over 15 years. The last time Apache's market share stood at 45% was in January 1998, at which time it served 830k hostnames. Despite gaining 18M new sites this month, 16M sites previously served by Apache no longer exist and a further 4M sites have moved to other web servers, including 1.5M sites to nginx and 420k sites to Microsoft. This loss was also seen in the SSL survey in which Apache lost 5.8k sites, but it continues to be the largest web server with 43% of the SSL market.

Microsoft saw the largest growth, gaining a net 16.5M hostnames. In May, it seemed inevitable that nginx would shortly match Microsoft in the number of sites served — there was just a single percentage point separating them. Microsoft’s growth has since accelerated however, and Microsoft now stand almost 5 percentage points above nginx. The next version of Microsoft's web server, IIS/8.5, has now been released to MSDN and TechNet subscribers ahead of the public release on the 18th October. More than 600 sites are already served by IIS/8.5, up 60% over last month.

Nginx gained 11.4M hostnames overall this month. Included in this was a net gain of 1.5M hostnames from Apache and a net loss of 340k hostnames to Microsoft. Among the top million, nginx gained 4.4k hostnames and the server is used by 15% of the top million sites.

All major server vendors suffered losses in the active sites metric resulting in a net decrease of 780k active sites, 664k of which belongs to Apache. In June 2000, when Netcraft started measuring active sites, 44% of sites were deemed active. The gap between the number of hostnames and active sites has been steadily increasing, and now the number of active sites account for less than a quarter of all sites.

ICANN signed 30 registry agreements for new top level domains in September. New gTLDs added this month include .reviews and .technology. General availability for domain registration of new gTLDs will begin in early 2014. The last new TLD to be seen in the wild is .post, a sponsored TLD first seen in October 2012. There were just 4 .post domains seen in the survey this month.





DeveloperSeptember 2013PercentOctober 2013PercentChange
Apache346,288,70646.86%344,408,38744.89%-1.97
Microsoft160,691,76321.74%177,216,29623.10%1.35
nginx111,680,07815.11%123,114,80016.05%0.93
Google34,806,5024.71%34,127,4824.45%-0.26
Continue reading

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