Search the Community

The road towards phasing out the ageing SHA-1 crypto hash function is likely to be littered with potholes, security experts warn. SHA-1 is a hashing (one-way) function) that converts information into a shortened "message digest", from which it is impossible to recover the original information. This hashing technique is used in digital signatures, verifying that the contents of software downloads have not been tampered with, and many other cryptographic applications. The ageing SHA-1 protocol – published in 1995 – is showing its age and is no longer safe from Collision Attacks, a situation where two different blocks of input data throw up the same output hash. This is terminal for a hashing protocol, because it paves the way for hackers to offer manipulated content that carries the same hash value as pukka packets of data. Certificate bodies and others are beginning to move on from SHA-1 to its replacement, SHA-2. Microsoft announced its intent to deprecate SHA-1 in Nov 2013. More recently, Google joined the push with a decision to make changes in he latest version of its browser, Chrome version 42, so that SHA-1 certificates are flagged up as potentially insecure. Nudge Ken Munro, a director at security consultancy Pen Test Partners, warned that this type of behaviour creates the danger that while SHA-2 is being phased in, trust in certificates will suffer. "The risk of not updating could see users learn not to trust your site (reduced custom) or could encourage them to accept less-than-perfect encryption or even invalid certificates," Munro explained. Just updating to SHA-2 is not as simple as it might seem, because of compatibility issues with Android and Windows XP. More specifically, Android before 2.3 and XP before SP3 are incompatible with the change (a fuller compatibility matrix maintained by digital certificate firm GlobalSign can be found here). Windows XP may have been put out to pasture last year, but it's still widely used. Older versions of Android also present a problem. Around one per cent of devices used for Google Play are still <2.3 (Froyo) or below. Whilst the current Play Store version doesn't work pre 2.2, that still indicates that around 20 million active devices are in use that aren’t compatible with SHA-2, according to Munro. "The fact that SHA-2 can’t be used with older browsers and OS’s means that untrusted certificate warnings are going to become commonplace," Munro explained. "And if that happens, the danger is that many users will simply ride rough-shod over such pop-ups, potentially creating the ideal opportunity for man-in-the-middle (MitM) attacks." Ivan Ristic, a software engineer and founder of SSL Labs, agreed with Munro that there might be some trouble with the phasing out of SHA-1, "as with all older technologies". "Websites with older audiences might consider deploying with dual certificates; older SHA-1 for older clients and newer SHA-2 for modern clients," Ristic told El Reg. "Not all web servers support this, however." "To prevent warnings in Chrome, sites must upgrade to SHA-2 by the end of this year. However, it's possible to continue to use SHA-1 certificates at least until the end of 2016. So this gives sites at least about 1.5 years." Baseline requirements from industry group the CA/Browser Forum (PDF) offer "room for a reasonably safe dual-cert deployment" for even longer, if really necessary, up until the start of 2017. Macro signing Browser compatibility is not the only issue. SHA-2 compatibility for macro signing isn’t great, according to Munro, who said "it simply doesn’t work for Office 2003/2007 macro signing". Office 2010 does support SHA-2 macro signing, but only with a hotfix. Munro added: "There are plenty of other systems out there that are unlikely to ever accept SHA-2: what about the web interfaces for SCADA and other industrial control systems? What about other highly customised environments in the military: fire control systems built on old hardened versions of Windows XP?" Microsoft made some changes/exceptions for code signing, according to Ristic. ® Bootnote Microsoft's IE will allow "CAs to continue to issue SSL and code signing certificates until January 1 2016, and thereafter issue SHA-2 certificates only”. Google's Chrome will handle sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include an SHA-1-based signature as part of the certificate chain, as “secure, but with minor errors”. Mozilla, makers of Firefox, has developed a policy that SHA-1 certificates should not be issued after January 1 2016, nor trusted after January 1 2017. Source

Firefox-maker Mozilla has joined Google in refusing to recognize SSL certificates issued by the China Internet Network Information Centre (CNNIC). This comes after a security biz in Egypt used a CNNIC-issued intermediate certificate to create unauthorized SSL certs that could be used to trick people into connecting to bogus, password-stealing Gmail.com or Google.com websites. Google, and now Moz, are outraged by CNNIC's sloppiness in the case. CNNIC is run by the Middle Kingdom's government, and handles the .cn domain name registry, IP address allocation and other things as well as issuing SSL certificates for encrypted websites via intermediaries. "After reviewing the circumstances and a robust discussion on our public mailing list, we have concluded that CNNIC's behaviour in issuing an unconstrained intermediate certificate to a company with no documented PKI practices and with no oversight of how the private key was stored or controlled was an 'egregious practice' as per Mozilla's CA Certificate Enforcement Policy," the Mozilla security team wrote in a Thursday blog post. As a consequence of the incident, all Mozilla products – including the Firefox web browser and the Thunderbird email client, among others – will be updated so that all CNNIC-based certificates issued on or after April 1, 2015 are considered untrusted. Mozilla said it also plans to ask CNNIC for a comprehensive list of all of its current valid certificates. Any certificates issued before April 1 that are not included on this whitelist will also be subject to potential "further action." The move comes following a similar action by Google, which said on Wednesday that it would stop recognizing the CNNIC certificate authority in a future update to its Chrome browser. As a result of these actions, Chrome and Firefox users who try to connect via encrypted HTTPS to websites that use CNNIC-issued SSL certificates will see alert messages warning them that their connections may not be secure – even for online banks, e-commerce shops, and other sites that manage sensitive information. CNNIC, which manages both China's .cn country code top-level domain and the system of internationalized domain names that contain Chinese characters, issued a declaration on Thursday condemning Google's ban: 1. The decision that Google has made is unacceptable and unintelligible to CNNIC, and meanwhile CNNIC sincerely urge that Google would take users' rights and interests into full consideration. 2. For the users that CNNIC has already issued the certificates to, we guarantee that your lawful rights and interests will not be affected. Mozilla added, though, that CNNIC could regain its standing but only after proving that it could be trusted with the responsibility of managing a root certificate authority. "CNNIC may, if they wish, re-apply for full inclusion in the Mozilla root store and the removal of this restriction, by going through Mozilla's inclusion process after completing additional steps that the Mozilla community may require as a result of this incident," the nonproifit's security team said. Source

Google's Chrome browser will stop trusting all digital certificates issued by the China Internet Network Information Center following a major trust breach last week that led to the issuance of unauthorized credentials for Gmail and several other Google domains. The move could have major consequences for huge numbers of Internet users as Chrome, the world's second most widely used browser, stops recognizing all website certificates issued by CNNIC. That could leave huge numbers of users suddenly unable to connect to banks and e-commerce sites. To give affected website operators time to obtain new credentials from a different certificate authority, Google will wait an unspecified period of time before implementing the change. Once that grace period ends, Google engineers will blacklist both CNNIC's root and extended-validation certificates in Chrome and all other Google software. The unauthorized certificates were issued by Egypt-based MCS Holdings, an intermediate certificate authority that operated under the authority of CNNIC. MCS used the certificates in a man-in-the-middle proxy, a device that intercepts secure connections by masquerading as the intended destination. Such devices are sometimes used by companies to monitor employees' encrypted traffic for legal or human resources reasons. It's one of the first times a certificate authority has faced such a banishment since the downfall of Netherlands-based DigiNotar in 2011. Other CAs, including US-based Trustwave, have also done what CNNIC did without getting the boot. While worldwide Chrome is the No. 2 most used browser, it had a commanding, 52-percent share in China last year, compared to 23 percent for IE. The move was announced on Wednesday evening in an update to last week's blog post disclosing the misissued certificates. The update left open the possibility that CNNIC may be reinstated at an undetermined future date if the group gives a detailed accounting of all currently valid certificates. The update read: As this post was being prepared, it wasn't clear if Mozilla or Microsoft planned to update Firefox and Internet explorer to also stop trusting CNNIC. Firefox 37, released this week, stopped trusting all certificates issued by MCS Holdings, and Microsoft has announced similar plans for Windows. Revoking trust in the root CNNIC certificate would be a much more disruptive course of action, since many more website certificates would be affected. Update 1: In an e-mailed statement, Mozilla Cryptographic Engineering Manager Richard Barnes said: "We believe it is very important to include the Mozilla community in these discussions, so we are taking a bit longer to announce our official plan. We expect to wrap up our discussion in mozilla.dev.security.policy soon, and in the meantime you can see the plan we are currently discussing here." The plan under consideration would: Reject certificates chaining to CNNIC with a notBefore date after a threshold date Request that CNNIC provide a list of currently valid certificates and publish that list so that the community can recognize any back-dated certs Allow CNNIC to re-apply for full inclusion, with some additional requirements (to be discussed on this list) If CNNIC's re-application is unsuccessful, then their root certificates will be removed Update2: Officials with CNNIC have issued a statement that's sharply critical of Google's move. It reads: Source

Microsoft has blacklisted a phony SSL certificate that’s been making the rounds and is in the process of warning the general public that the certificate could be leveraged to stage man-in-the-middle attacks. In a security advisory published yesterday the company stressed that an improper certificate for the domain “live.fi” could also be used to spoof content or carry out phishing attacks, but stopped short saying it could issue other certificates, impersonate other domains, or sign code. The certificate, which corresponds to one of the company’s Live entities, was revoked by its issuer, certificate authority Comodo, and Microsoft has updated its Certificate Trust List (CTL) to reflect the instability. The company maintains an often in-flux Certificate Trust List as a running tally of trusted entities that are rooted to verifiable certificates. Microsoft blamed the botched certificate on a misconfigured privileged email account on the live.fi domain. It sounds like unauthorized third party was able to register an email account on the domain with a “privileged username,” and in turn used it to request a bogus certificate for live.fi. In a FAQ on its site, Comodo claims that all of its certificates must pass through Domain Control Validation (DCV) before they’re issued. It appears the aforementioned third party used an email (admin@, administrator@, postmaster@, etc.) to prove ownership of the domain and subsequently the certificate. Windows 8, 8.1, RT, RT 8.1, Server 2012 and Server 2012 R2 all contain an automatic updater that takes note of revoked certificates. The company warns that users who either opt not to run that automatic updater or run older setups, including Server 2003, should run the manual update KB2917500 to blacklist the certificate. It’s expected both Google Chrome and Mozilla Firefox will block the certificate over the next several days or so. In the very near future Firefox is expected to loop in a new feature, OneCRL, that will supersede the dated Online Certificate Status Protocol (OCSP) and improve upon the process in which the browser reviews and revokes certificates. Source

Google and Firefox have upgraded their flagship browsers, crushing bugs and cracking down on bad certificates along the way. The Choc Factory's Chrome 41 swats 51 bugs of which at least 13 are classified as high severity and six considered medium risks. Google engineer Penny MacNeil thanked security researchers for the effort to identify the bugs. "We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel," MacNeil says. Here's this month's ameliorated messes: [$7500][456516] High CVE-2015-1212: Out-of-bounds write in media. Credit to anonymous. [$5000][448423] High CVE-2015-1213: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$5000][445810] High CVE-2015-1214: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$5000][445809] High CVE-2015-1215: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$4000][454954] High CVE-2015-1216: Use-after-free in v8 bindings. Credit to anonymous. [$3000][456192] High CVE-2015-1217: Type confusion in v8 bindings. Credit to anonymous. [$3000][456059] High CVE-2015-1218: Use-after-free in dom. Credit to cloudfuzzer. [$3000][446164] High CVE-2015-1219: Integer overflow in webgl. Credit to Chen Zhang (demi6od) of NSFOCUS Security Team. [$3000][437651] High CVE-2015-1220: Use-after-free in gif decoder. Credit to Aki Helin of OUSPG. [$2500][455368] High CVE-2015-1221: Use-after-free in web databases. Credit to Collin Payne. [$2500][448082] High CVE-2015-1222: Use-after-free in service workers. Credit to Collin Payne. [$2000][454231] High CVE-2015-1223: Use-after-free in dom. Credit to Maksymillian Motyl. [449610] High CVE-2015-1230: Type confusion in v8. Credit to Skylined working with HP’s Zero Day Initiative. [$2000][449958] Medium CVE-2015-1224: Out-of-bounds read in vpxdecoder. Credit to Aki Helin of OUSPG. [$1000][446033] Medium CVE-2015-1225: Out-of-bounds read in pdfium. Credit to cloudfuzzer. [$1000][456841] Medium CVE-2015-1226: Validation issue in debugger. Credit to Rob Wu. [$1000][450389] Medium CVE-2015-1227: Uninitialized value in blink. Credit to Christoph Diehl. [$1000][444707] Medium CVE-2015-1228: Uninitialized value in rendering. Credit to miaubiz. [$500][431504] Medium CVE-2015-1229: Cookie injection via proxies. Credit to iliwoy. Mozilla's updates Firefox version 37 include a revocation feature to bolster the killing of bad intermediate certificates. The OneCRL replaces the Online Certificate Status Protocol which is less effective because it relies on third parties to keep updated registries of their valid and revoked certificates. Certificates were often accepted as soft-fails when the status could not be determined due to some technical or connectivity failure. Mozilla's new list operates in the browser and is populated by issuers who push certificate status instead of the browser having to do the fetching. This block-list, already used for blacklisting bad plugins and drivers, will now speed up checking times because it avoids the need for Mozilla to push out updates that require browser restarts, Mozilla security boffin Mark Goodwin says. "OneCRL helps speed up revocation checking by maintaining a centralised list of revoked certificates and pushing it out to browsers. Currently, if a serious incident occurs that requires certificates to be revoked, we release an update to Firefox to address the problem. "This is slow because it takes some time for users to get the security update and restart their browsers. There’s also cost involved in producing an update and in users downloading it." Goodwin points to a blog by Google guy Adam Langley who said last year that the old revocation checking did little to improve security. OneCRL for now covers intermediate certificates to reduce the size of Mozilla's blocklist and will be later sped up by automating the collection of revoked certificates. Source