The length of an RSA public key gives an indication of the strength of the encryption — the shorter the public key is; the easier it is for an attacker to brute-force. An attacker, armed with a compromised private key derived from a short public key, would be able to decrypt both past and future SSL-secured connections if she were able to incept the encrypted traffic. She could also impersonate the organisation to which the SSL certificate was issued if she has the opportunity to manipulate DNS lookups. Both the CA/B Forum (a consortium of certificate authorities (CAs) and major browser vendors) and NIST [PDF] (the agency which publishes technical standards for US governmental departments) have recommended that sub-2048-bit RSA public keys be phased out by the end of 2013.

According to the CA/B Forum's own Baseline Requirements [PDF] — effective 1st July 2012 — member certificate authorities are required to reject a request to sign an RSA public key shorter than specified in the following table:

Nevertheless, these key sizes are not guaranteed as several CA/B Forum members have issued several non-compliant SSL certificates since 1st July 2012. Trustwave, Symantec, KEYNECTIS, and TAIWAN-CA have all signed certificates which fall foul of their organisation's requirement of 2048-bit RSA public keys for certificates expiring after 2013, demonstrating that the key length requirement is being treated as a guideline (which by definition is neither binding nor enforced), rather than a rule.

They are by no means the only CAs signing short RSA public keys: more than 10 years after Netcraft's first blog post on the topic and 12 years after RSA-155 [PDF], 512-bit RSA public keys are still appearing in SSL certificates. A 512-bit RSA public key was signed as recently as July 2012 by Swisscom.

Most, but not all, of the major browser and operating system vendors either disallow access or display a warning message when accessing a website using an SSL certificate with a 512-bit RSA public key. The latest versions of Safari (although not the mobile version on iOS 5.1), Opera, Google Chrome, and Internet Explorer (via an update to Windows; planned to be rolled out in October 2012). Notably, Mozilla Firefox does not yet reject such certificates.

More than a thousand websites – including several government sites – are still using SSL certificates with weak signature algorithms.

Netcraft's August 2012 SSL Survey shows there are 1,300 websites still using SSL certificates that have been signed using the cryptographically weak MD5 digest algorithm. This algorithm is demonstrably vulnerable to several types of attack, including collision attacks.

The first use of this vulnerability against SSL was demonstrated back in December 2008, when security researchers showed how an MD5 hash collision could be exploited to create a rogue certificate authority (CA) certificate that would be trusted by all common web browsers. This rogue certificate could have been used to sign arbitrary subscriber certificates, thus allowing an attacker to convincingly impersonate any secure website on the internet.

At the time of the 2008 discovery, Netcraft's SSL Survey showed that 14% of all SSL certificates were signed using the vulnerable MD5 algorithm.

A few months later, the developers of Google Chrome suggested that some browser developers would be dropping support for MD5-signed certificates at some point; however, given the number of sites still using MD5-signed certificates, it was thought that suddenly removing support for such certificates would have a undesirably large impact on users.

As the majority of MD5-signed certificates have since expired or been replaced, browser vendors and certificate authorities have been gradually phasing out support for such certificates. Apple removed support for MD5-signed certificates in an iOS 5 update last year, and Chrome's developers subsequently revisited the issue and revised their browser to display an interstitial warning about MD5 being a weak signature algorithm. This immediately caused problems for users of certain corporate proxies, where a man-in-the-middle approach was used to decrypt SSL traffic before presenting it to the client with a trusted MD5-signed certificate.

The CA GeoTrust has added the affected certificates to its certificate revocation lists at http://www.geotrust.com/resources/repository/crls/, which has resulted in the certificates being rejected as invalid in many of today's browsers, including Chrome, Opera and Internet Explorer. However, sites which currently use MD5-signed certificates can be viewed with the latest version of Mozilla Firefox without receiving any warnings, as the relevant certificate revocation lists have to be added manually, and none of the certificates specifies an OCSP server for checking the revocation status.

The CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [pdf] no longer allow the MD5 digest algorithm to be used for root, subordinate or subscriber certificates. All but two of the 1,123 unique MD5-signed certificates still in use on the web were issued by Equifax between 2006 and 2008, with validity periods ranging between 4 and 6 years.

The remaining two MD5-signed certificates were issued by VeriSign. These do not appear to have been revoked, but are due to expire in less than a month. In the worst case, all MD5-signed certificates currently in use on the web will have expired naturally by March 2014, regardless of whatever measures have been taken by browser vendors and certificate authorities.

Several government websites are currently operating with MD5-signed certificates, including a few in Australia, a couple in New Zealand, and one in each of Ireland and the UK. The most recently issued certificates are marked as being valid from 30th December 2008 – the same day as the publication of the hash collision demonstration.

Other notable users of weak MD5-signed certificates include Reliance Bank, Commencement Bank, several online billing websites, dozens of corporate webmail services, purportedly secure hosting providers, a number of schools and universities, and even a reseller of GeoTrust SSL certificates.

Over the years the Internet community has been taught that one of the key steps in protecting their personal information on the Internet is to ensure that it is entered only over an encrypted connection, perhaps by looking for the lock symbol in the browser address bar or web addresses beginning with https://. As a result, phishing attacks which make use of SSL certificates are especially dangerous  as most users associate the presence of a valid SSL certificate with an increased level of assurance. Such attacks  erode the reputation of Certificate Authorities and SSL certificates, which makes identifying and revoking maliciously used certificates a material issue.

Netcraft's anti-phishing feed has blocked over 5 million unique phishing sites to date, receiving over 4 reports a minute from our reporter community, and while the majority of phishing attacks run over HTTP,  a significant number run on sites for which SSL certificates have been issued. In July 2012 alone, Netcraft found 505 unique valid certificates on blocked sites.

The following table, produced for the Netcraft SSL Survey, shows the number of unique valid certificates returned by phishing sites that were blocked by Netcraft in July 2012:

The columns of the table are ordered left to right by trustworthiness, as using a valid SSL certificate is not always enough to trick a user into trusting a phishing website and two further conditions have to be met:

• The Subject Common Name of the certificate has to match the hostname of the phishing site that returned it. Some sites will return the hosting company's certificate when requested over HTTPS. As most modern browsers display warnings when a non-matching certificate is encountered (pictured below), such certificates only serve to make the user more suspicious instead of increasing the perceived security of the site.


• The phishing attack has to actively use the SSL certificate by including https:// in the phishing URL. Having a valid SSL certificate does not make a phishing site appear more trustworthy if victims only access it over HTTP.

Fraudsters will often host their phishing content on a compromised website and so can make use of the website's legitimate certificate, however they may not have realized that SSL services are available and so serve the content over HTTP. None of the certificates found on phishing sites in this period appeared to have been issued specifically for the purpose of phishing.

Taking Certificate Authority market shares into consideration, Go Daddy has a lower proportion of its SSL certificates used in phishing attacks than the other large CAs, in part because it provides the hosting for a large proportion of the certificates which they issue and is a long term user of Netcraft's feed to remove phishing attacks.

Top of the table this month is Swishmail, which offers a variety of managed web hosting plans in addition to their core service of enterprise-grade email hosting.

INetU is at second place this month, which offers dedicated managed hosting services from data centres with resilient networks, backup power, and strong physical and network security. INetU also offers compliance and consultancy services to customers around the world and has recently received PCI DSS certification for their cloud service.

In third place is the California-based Multacom, which provides web hosting, dedicated servers, colocation, and managed services. Multacom's data centre is in downtown Los Angeles and offers fibre-optic links to many other carrier buildings both in Los Angeles and worldwide.

Within the top 10, Linux and FreeBSD were used by 4 hosting companies each, and Microsoft was used by 2. For the first time since July 2010, Linux was not used by any of the hosting companies in the top 4.

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.

Social network Bebo is still inaccessible after an apparent technical error took the site offline yesterday.

Bebo was previously hosted on the Akamai content delivery network, which generally increases a site's resilience to network outages and traffic spikes, but DNS lookups for the www.bebo.com website are currently not resolving:

$ ping www.bebo.com
ping: cannot resolve www.bebo.com: Host name lookup failure

$ dig www.bebo.com
; <<>> DiG 9.5.1-P3 <<>> www.bebo.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

Twitter is currently awash with self-propagating rumours that Bebo has been shut down for good; however, this has been debunked by TechCrunch, which reports a Bebo spokesperson as saying the site went down due to "a technical clusterf**k". Michael Birch, who originally founded Bebo with his wife Xochi, also tweeted that the site should be coming back in a matter of hours.