1. NIST continues using SHA-1 algorithm after banning it

    The National Institute of Standards and Technology (NIST) is still using SSL certificates signed with the SHA-1 signature algorithm, despite issuing a Special Publication disallowing the use of this algorithm for digital signature generation after 2013.

    "SHA-1 shall not be used for digital signature generation after December 31, 2013."
    — NIST recommendation

    The SSL certificate for www.nist.gov is signed using the SHA-1 hashing algorithm, and was issued by VeriSign on 23 January 2014, more than three weeks after NIST's own ban came into effect. Also issued this year, NIST's "Secure File Transfer Service" at xnfiles.nist.gov uses a SHA-1 certificate.

    An attacker able to find SHA-1 collisions could carefully construct a pair of certificates with colliding SHA-1 hashes: one a conventional certificate to be signed by a trusted CA, the other a sub-CA certificate able to be used to sign arbitrary SSL certificates. By substituting the signature from the CA-signed certificate into the sub-CA certificate, certificate chains containing the attacker-controlled sub-CA certificate will pass browser verification checks. This attack is, however, made more difficult by path constraints and the inclusion of unpredictable data into the certificate before signing it.

    The increasing practicality of finding SHA-1 hash collisions could make it possible for a well-funded attacker to impersonate any HTTPS website. With a practical attack against SHA-1 (using cloud computing resources) estimated to cost $2.77M in 2012, falling to $700k by 2015, it may attract government agencies.

    The SSL certificate for www.nist.gov with the signature algorithm and issuance date highlighted.

    Along with NIST itself, many US Government institutions have continued to generate new SSL certificates with SHA-1 signatures. Examples include the certificate for donogc.navy.mil, issued on 3 January 2014, and several United States Bankruptcy Court document filing systems (each state has its own site and uses its own SHA-1-signed SSL certificate). Despite receiving widespread criticism for a number of other security problems last year, the ObamaCare exchange at healthcare.gov also saw fit to deploy a new SSL certificate in January which uses the SHA-1 hashing algorithm.

    NIST and the rest of the US government are far from alone, however, as more than 92% of all certificates issued this year use the SHA-1 hashing algorithm.

    Although the recommendations from the National Institute of Standards and Technology have been prepared for US federal agencies, the cryptographic weaknesses of SHA-1 should concern anyone who relies on SHA-1 to generate or validate digital signatures. Microsoft shares these concerns and has announced plans to deprecate the use of SHA-1 in both SSL and code signing certificates by the end of 2016.

    The NSA-designed SHA-2 family (which includes SHA-224, SHA-256, SHA-384 and SHA-512) now provides the only cryptographic hash functions approved by NIST for digital signature generation. Whilst SHA-2 shares some similarities with SHA-1, there are significant structural differences: SHA-2 does not share the SHA-1's mathematical weakness. All of the SHA-2 algorithms have much longer digests: SHA-1 only produces a 160-bit digest, whereas the most common digest length for SHA-2 is 256-bits.


    Huge divide: SHA-256 uptake remains low, and is still only used by a handful of certificate authorities.
    Other signature algorithms with negligible shares (e.g. MD5 and SHA-512) are not displayed.

    In total, more than 98% of all SSL certificates in use on the Web are still using SHA-1 signatures. Netcraft's February 2014 SSL Survey found more than 256,000 of these certificates would otherwise be valid beyond the start of 2017 and, due to the planned deprecation of SHA-1, will need to be replaced before their natural expiry dates.

    SHA-256 is the most commonly used signature algorithm from the SHA-2 family, but it is used by only 1.86% of the valid certificates in Netcraft's February 2014 SSL Survey; nonetheless, this share has more than doubled in the space of 4 months, suggesting that some certificate authorities are starting to take the issue seriously. So far in 2014, more than 61% of the new certificates signed with SHA-256 were issued by a single certificate authority, Go Daddy. SHA-512 is the only other SHA-2 family algorithm to be seen used in SSL certificates, albeit deployed on only 4 websites so far.

    The CA/B Forum – which comprises of both certificate authorities and web browser vendors – put forward Ballot 111 last year, which motions to take advantage of the deprecation of SHA-1 by accelerating the forum's planned move to shorter maximum certificate lifetimes. The deprecation alone will mean that some five-year certificates that are valid today will not be usable for their entire lifetime.

    In practice, it is likely to be Microsoft's plans to deprecate the use of SHA-1 signatures by the end of 2016 which will force the mass adoption of SHA-2 by certificate authorities, although allowing three years for this to happen might seem generous. The majority of end users are unlikely to be affected by the change, and most website administrators will probably have to renew their SSL certificates within this period anyway, but certificates which are reissued with SHA-1 signatures run the risk of being unsupported by other browsers in the future.

    Cryptographic weaknesses in SHA-1 have been discussed for several years. A notable better-than-brute-force attack was announced nine years ago, demonstrating a SHA-1 hash collision that could be achieved within 269 calculations, as opposed to the 280 that would be required by a brute-force approach.

    More recently, the best public cryptanalysis of SHA-1 estimated that a full collision can be achieved with a complexity of around 261, while a near-collision can be achieved in 257.5. These attacks have been implemented in the HashClash framework, which provides differential path construction attacks against SHA-1, as well as chosen prefix collisions against the even-weaker MD5 algorithm. The CA/B Forum recommends that all certificate serial numbers should exhibit at least 20 bits of entropy, which would mitigate chosen-prefix collision attacks for non collision resistant hash functions, although such measures are not thought to be necessary for SHA-2 at the current time.

    Windows XP has supported SHA-256, SHA-384 and SHA-512 since the release of Service Pack 3 in 2008, and Windows Server 2003 can also support SHA-2 if the KB938397 hotfix has been installed. Deprecating SHA-1 could therefore also have some other indirect security benefits: anyone still using Windows XP before Service Pack 3 will be unable to make effective use of the web as SHA-2 certificates gain prominence.

    The SHA-1 algorithm is also used in all versions of the TLS cryptographic protocol, and only the latest version (TLS 1.2) introduces SHA-256 as a replacement for the MD5/SHA-1 combination for both the pseudorandom function and the finished message hash. Microsoft's SHA-1 deprecation policy will only apply to applications which call the CertGetCertificateChain API to build and validate a certificate chain, so older browsers and hardware devices which do not yet support TLS 1.2 will be unaffected.

    Update 5 Feb 2014: Following the publication of this article, NIST today replaced the SHA-1 certificate on www.nist.gov with a new one which uses SHA-256 as a signature algorithm. At the time of writing, the certificate used by xnfiles.nist.gov is still signed with SHA-1.

    Posted by Paul Mutton on 4th February, 2014 in Dogfood, Security

  2. Incentives for Phishing Site Reporters

    As of the 1st November 2013, the Netcraft Anti-Phishing community has helped to block over 6.9 million phishing attacks worldwide. We incentivise phishing reports from the community, and have now added a Netcraft USB Flash Drive to our list of incentives:

    Prize When
    Netcraft USB Flash Drive after 100 validated phishing reports
    Netcraft Mug after 250
    Netcraft Polo Shirt after 500
    Targus Laptop Backpack after 1,000
    iPad after 5,000

    On reaching 5,000 validated reports you become eligible for a monthly competition to incentivise large reporters.

    To report phishing sites to us, please use the form at http://toolbar.netcraft.com/report_url, or forward any phishing URLs or emails you receive to scam@netcraft.com.

    The Netcraft Extension, which is available for Firefox, Google Chrome™ and Opera, serves as a giant neighbourhood watch scheme for the Internet. Members who encounter a phishing site can act to defend the larger community of users against the attack. Once the first recipients of a phishing mail have reported the attack URL, it is blocked for community members as they subsequently access the URL. Widely disseminated attacks simply mean that the phishing attack will be reported and blocked sooner.

    Anti-Phishing Chrome Extension Netcraft Toolbar for Firefox Netcraft Toolbar for Opera

    Posted by Jason Robins on 14th November, 2013 in Netcraft Services, Other, Security

  3. PHP.net blocked by Google: False positive or not?

    Rasmus Lerdorf – the creator of PHP – is currently trying to get Google to stop blocking the whole php.net website after it was suspected of containing malware. In a tweet earlier this morning, Rasmus posted a screenshot and suggested that the block was caused by a false positive:

    Google's Webmaster Tools flag the inclusion of the script at http://static.php.net/www.php.net/userprefs.js as suspicious, although this file currently appears benign. However, Google's Safe Browsing diagnostics for php.net do suggest that malware has been present on the site in the last 90 days:

    "Of the 1513 pages we tested on the site over the past 90 days, 4 page(s) resulted in malicious software being downloaded and installed without user consent."

    The block was added to add chunk 127721 in the Google Safe Browsing goog-malware-shavar list. At the time of writing, php.net is still blocked in Firefox and Chrome, both of which make use of Google's blocklist. Visiting php.net from a Google search results page or the bitly URL shortener causes an interstitial warning page to be displayed.

    A seemingly benign, yet obfuscated, JavaScript file called functions.js was removed from the PHP website repository this morning. The developer behind this change speculated that the file "Could be the reason why Google is blocking us today.."

    However, a short moment ago, a Hacker News user posted some obfuscated JavaScript that was found appended to a possibly cached version of the userprefs.js script, suggesting that the PHP.net website may have been compromised recently. The obfuscated JavaScript inserts an iframe into the webpage, which loads content from an external site known for distributing malware. Google Chrome blocks the inclusion of any content from known malware domains, although the injected content in this case no longer appears to be accessible.


    Using Firebug to display the injection point of the iframe (iframe has been moved to a visible location)

    Update [Monday 28th October]: The administrators of PHP.net have since confirmed that two web servers were compromised and at least one was serving malware. The affected servers have been taken offline and the SSL certificate in use has been revoked by Comodo. The PHP source packages and code repository were reportedly not compromised.

    Posted by Paul Mutton on 24th October, 2013 in Security

  4. US Government aiding spying… against itself

    Partly as a consequence of the US Government shutdown, there are presently more than two hundred .gov websites using expired SSL certificates. Although the shutdown is expected to be a short term measure, the widespread use of expired certificates on .gov sites may cause long term harm. The US Government is effectively training its citizens and employees to click through SSL warnings, and once the users of a website treat SSL error messages as normal, attackers may be able to perform otherwise difficult man-in-the-middle attacks.

    The situation is exacerbated by the behaviour of some mainstream browsers which do not faithfully warn the user of the most serious problem in scenarios where two or more errors are present.

    An SSL error message presented on EV-enabled www.usaspending.gov in Google Chrome.

    When an SSL error occurs, some browsers only display a single error message, sometimes not the most serious, or even a generic error message for all types of SSL error. An attacker can exploit this vulnerable browser behaviour on SSL sites with expired certificates to perform an almost seamless man-in-the-middle attack. By signing his own expired SSL certificate for a US government website, the SSL error message displayed for the attacker's SSL certificate is indistinguishable (in some browsers) from the error message produced by the real SSL certificate belonging to the US Government. Citizens accustomed to seeing the "expired" error message will happily proceed with a connection using the attacker's expired (and untrusted) certificate, unwittingly communicating with the attacker instead of the US Government.

    By testing an expired certificate signed by an expired untrusted issuer, Netcraft found that whilst some browsers are vulnerable, Internet Explorer is not as it correctly displays both error messages. Google Chrome on Windows and OS X displays the more serious error message but does not display a warning about the expiry. All other tested browsers displayed either a generic error message or did not mention that the issuing CA is not widely trusted. Generic error messages are dangerous if they hide the severity of the SSL error from the user: a change in the type of the SSL error (from expiry to an untrusted issuer) will not be noticed. The tested website contained in the screenshots below is not on a .gov domain, but demonstrates browser behaviour with an untrusted and expired CA certificate with an expired end-entity certificate.

    Google Chrome displaying an error message for an expired SSL certificate issued by an untrusted CA. From left to right: Windows, Mac OS X, Linux, and Android.

    Google Chrome's behaviour is not consistent across its supported platforms: on Windows and Mac OS X it displays the most serious SSL error message, namely that an untrusted issuer has signed this SSL certificate. On Linux and Android, however, Google Chrome displays an error message about the expired certificate and does not mention the untrusted issuer. By reading the error message and accepting the risks of trusting an expired certificate, a user may unwittingly trust an SSL certificate that was not issued by a widely trusted CA.

    Internet Explorer and Opera displaying an error message for an expired SSL certificate issued by an untrusted CA.

    On Windows, Internet Explorer correctly presented both applicable error messages. Opera presented the more serious error message though only after viewing an additional dialogue box. Once a user is accustomed to accepting Opera's generic error message, any other type of SSL error on the same website is unlikely to be noticed. Internet Explorer, Google Chrome, and Opera all use Microsoft's CryptoAPI on the Windows platform which may explain their similar behaviour.

    Firefox displaying an error message for an expired SSL certificate issued by an untrusted CA.

    Firefox, which displays a generic error message for most SSL errors, has further information hidden by default. For an expired certificate issued by an untrusted and expired CA, Firefox's error message refers only to expired certificates (both the CA and end-entity certificates) and does not make any mention of the issuer not being a widely-trusted CA. Hidden details mean that a user having seen the same error message on the .gov website may not notice a change in the category of the SSL error message.

    Safari (on OS X and iOS) displaying an error message for an expired SSL certificate issued by an untrusted CA.

    Safari on OS X, like both Firefox and Opera displays a generic error message. If the message is expanded, Safari displays an error message based on the expired certificate and will also highlight the lack of trust in the issuer. Safari on iOS 7 displays a generic error message, "Not trusted", for many types of SSL certificate error — it is difficult to tell what is wrong with the SSL certificate without examining the certificate in detail.

    Even without the "training" from the US Government, the click-through rate of different SSL messages has been demonstrated to be very high. For Firefox, which doesn't display full error messages by default, Akhawe and Porter Felt found SSL error messages were bypassed in 85% of cases: 87% for untrusted issuer messages and 81% for expired certificate errors. Paradoxically, in Google Chrome expired certificate error messages were dismissed 57% of the time whereas error messages for an untrusted issuer (the more serious problem) were dismissed in 82% of studied cases.

    Posted by Robert Duncan on 16th October, 2013 in Security

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

    Posted by Paul Mutton on 7th October, 2013 in Security

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

    Posted by Robert Duncan on 1st October, 2013 in Around the Net, Security

Page 3 of 5412345102030...Last »