Facebook farewells flaky SHA-1

FacebookFacebook has set the date: on September 30, the ancient and creaking SHA-1 hashing algorithm will make its tumbril trip and get the chop.

SHA-1, designed by the NSA in 1995, is a one-way algorithm: a block of data is turned into a message digest. The digest can’t be turned back into the original message, but serves as a digital signature confirming the authenticity of (for example) the software you’ve downloaded.

And it’s long been on the end-of-life list, because it’s vulnerable to collision attacks – different blocks of data can present the same SHA-1 hash, allowing malware to verify as if it were authentic.

From October 1, The Social NetworkTM says, third-party apps signed with SHA-1 will no longer be able to connect to Facebook.

As Facebook’s Adam Gross blogs, the move is in line with the Certificate Authority and Browser Forum’s intention to sunset SHA-1 by January 2016.

“We’ll be updating our servers to stop accepting SHA-1 based connections before this final date, on October 1, 2015. After that date, we’ll require apps and sites that connect to Facebook to support the more secure SHA-2 connections”, Gross wrote.

Facebook recommends that “applications, SDKs, or devices that connect to Facebook” be checked for SHA-2 support, to avoid user irritation.

The migration hasn’t been without its detractors. Earlier this year, infosec bods told The Register the shift poses challenges. If users see disruption – for example, too many “insecure site” warnings – they fear that trust in the Internet will be undermined.

Cross-posted from TheRegister

Firefox switching to encrypted Google search

logo-wordmarkThe H-Online: An inconspicuous “s” added to various ​lines of code in its latest nightly builds means that future versions of Firefox will send all search queries to Google in encrypted form. This means that instead of HTTP, the open source browser will use the HTTPS protocol, which encrypts traffic between the web site and browser using SSL. The nightly builds will feed through, over the next few months, until the feature is, most probably, in Firefox 14.

The change has been prompted by a discussion between Firefox developers which started about a year ago. Then, Google opposed making SSL the default, with Adam Langley, a member of Google’s security team, explaining that the encrypted search was slower than the standard unencrypted search.

Google has since made encryption the global default for its own search site, though only for signed-in users. In early February, the Firefox development team gave the green light for the change to go ahead in the browser as well.

The switch to SSL means that only Google will be able to read search queries. According to Danny Sullivan, ​writing on his Search Engine Land blog, they will, however, continue to be contained in the referrer header which the browser sends to the relevant web site when a user clicks on an advert. He has asked both the Firefox and Internet Explorer development teams whether they would stop sending this critical referrer data, but has not received a response from either browser maker.

Google is globally switching its search to HTTPS by default

GoogleThe H-Online: Google has announced on its Inside Search blog that it is enabling SSL encryption by default on its global search pages. The US site Google.com has been switching users to the secured HTTPS protocol since last year and now, to improve security and privacy for all its users, the company is rolling the behavior out to its international properties such as google.co.uk.

As is the case on the US site, this only affects users who are signed into their Google account when visiting the site. The company expects to roll out this feature to the different local Google search pages “over the next few weeks”. Google hopes that this move will encourage other companies to adopt SSL more broadly across their web sites as well.

HTTPS Everywhere reaches 2.0, comes to Chrome as beta

HTTPS_Everywhere_new_logo200H-Online: Version 2.0 of the HTTPS Everywhere browser extension has been released. Where possible, the add-on automatically redirects users to more secure HTTPS connections when they access certain web pages. HTTPS Everywhere 2.0 includes an optional “Decentralised SSL Observatory” feature that detects weaknesses in encryption.

When the extension detects an encryption issue, such as weak keys, it notifies users that the site they are visiting may contain security vulnerabilities that could be used to for man-in-the-middle (MITM) attacks. “This is an extra level of protection that we encourage Firefox users to download, install, and use” said Electronic Frontier Foundation (EFF) Technology Projects Director Peter Eckersley.

The updated extension is available for Mozilla’s Firefox and has been translated into 12 languages. A beta version is now available for Google’s Chrome browser. The new beta Chrome version includes the same features as older versions of HTTPS Everywhere; however, it does not yet include the functionality to notify users of weak key vulnerabilities and other certificate problems.

Further information about the new versions can be found in the official release announcement and in the change log. Version 2.0.1 of HTTPS Everywhere for Firefox and a beta version for Chrome are available to download from the EFF.

First started in June 2010, HTTPS Everywhere is a collaboration between the EFF and the Tor Project. Source code for HTTPS Everywhere is licensed under the GPLv2 and is available from project’s development page.

Twitter enables HTTPS for all signed-in users

twitter-logo200The H-Online: Twitter has announced that it has now enabled HTTPS by default for all users signed into the micro-blogging service. By using HTTPS, all user information including log-in credentials transmitted to the company’s servers are sent using SSL encryption. This means that all data is transmitted in encrypted form and can no longer be read and exploited for fraudulent activities by attackers using tools such as the Firesheep extension for Firefox.

The company originally added the “Always use HTTPS” option in March of last year but required users to manually enable it. Later, in August, it began to enable the setting by default for “some” of its users. Those who prefer not to use HTTPS can still disable it by unchecking the “Always use HTTPS” setting on the Account Settings page. More details about HTTPS on Twitter and keeping an account secure can be found in the Twitter Help Center.

Google plans to turn off online checks for SSL certificate validity

new-chrome-logoThe H-Online: Google plans to turn off online checks for SSL certificate validity in its Chrome browser soon, according to a blog post by Adam Langley, the developer in charge of that element of the browser. Instead, the browser will use the update mechanism to receive lists of revoked certificates.

When browsers make a connection, they check whether the certificate presented by the server has already been blocked by the certificate authority, using either the certificate authority’s certificate revocation lists (CRLs) or, directly and interactively, the Online Certificate Status Protocol (OCSP). But that whole process has never been completely reliable, since, if the browser isn’t certain of the validity – if, say, an OCSP request doesn’t work – it simply “looks the other way”. Otherwise, there would be too many false alarms.

At the same time, an attacker manipulating SSL connections can generally also interrupt OCSP requests, as clearly demonstrated by tools such as sslsniff. When the breach at Comodo resellers made certificate revocations necessary, browser developers were obliged to embed those revocations into their browsers through updates.

Since OCSP requests significantly extend the loading time for SSL pages even during normal operations, Google plans to make the best of the situation. In future, the online checks will be done away with and replaced with lists that are renewed through an existing update mechanism which doesn’t require the browser to restart and makes the updated lists available immediately. Langley is inviting the certificate authorities to contribute their revocation lists to Google’s browser revocation list before Google implements the changes. Whether, and to what extent, this change will also affect extended validation certificates remains to be seen.

An update on attempted man-in-the-middle attacks

Google: Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).
Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.

To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates. Microsoft also has taken prompt action.

To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.