Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0

Almost everyone has now migrated to TLS 1.2, and a few have moved to TLS 1.3.

A green exterior door is sealed with a padlock.

Enlarge (credit: Indigo girl / Flickr)

Apple, Google, Microsoft, and Mozilla have announced a unified plan to deprecate the use of TLS 1.0 and 1.1 early in 2020.

TLS (Transport Layer Security) is used to secure connections on the Web. TLS is essential to the Web, providing the ability to form connections that are confidential, authenticated, and tamper-proof. This has made it a big focus of security research, and over the years, a number of bugs that had significant security implications have been found in the protocol. Revisions have been published to address these flaws.

The original TLS 1.0, heavily based on Netscape's SSL 3.0, was first published in January 1999. TLS 1.1 arrived in 2006, while TLS 1.2, in 2008, added new capabilities and fixed these security flaws. Irreparable security flaws in SSL 3.0 saw support for that protocol come to an end in 2014; the browser vendors now want to make a similar change for TLS 1.0 and 1.1.

Read 2 remaining paragraphs | Comments

Google taking new steps to prevent malicious Chrome extensions

Company plans stricter rules for developers, and greater control for users.

Article intro image

Google has announced plans to further restrict Chrome extensions in a bid to crack down on the number of malicious extensions found in the Chrome Web Store.

We've seen a spate of malicious extensions this year; the extensions do things like steal credentials and participate in click fraud schemes. The malicious extensions take advantage of the considerable access to Web pages that extensions have.

Google has already taken some steps to limit malicious extensions. Last year, a stricter multi-process model was applied to extensions to limit the impact of security flaws in the browser, and earlier this year Google deprecated the ability for extensions to offer installation from third-party websites (instead forcing all installations to go via the Chrome Web Store). This feature will be fully removed in Chrome 71 in December.

Read 5 remaining paragraphs | Comments

Google backtracks—a bit—on controversial Chrome sign-in feature

Privacy-conscious users were unhappy at being signed in to browser without consent.

Article intro image

Enlarge (credit: Google Chrome)

Google will partially revert a controversial change made in Chrome 69 that unified signing in to Google's online properties and Chrome itself and which further preserved Google's cookies even when users chose to clear all cookies. Chrome 70, due in mid-October, will retain the unified signing in by default, but it will allow those who want to opt out to do so.

Chrome has long had the ability to sign in with a Google account. Doing this offers a number of useful features; most significantly, signed-in users can enable syncing of their browser data between devices, so tabs open on one machine can be listed and opened on another, passwords saved in the browser can be retrieved online, and so on. This signing in uses a regular Google account, the same as would be used to sign in to Gmail or the Google search engine.

Prior to Chrome 69, signing in to the browser was independent of signing in to a Google online property. You could be signed in to Gmail, for example, but signed out of the browser to ensure that your browsing data never gets synced and stored in the cloud. Chrome 69 unified the two: signing in to Google on the Web would automatically sign you in to the browser, using the same account. Similarly, signing out of a Google property on the Web would sign you out of the browser.

Read 6 remaining paragraphs | Comments

Google wants to get rid of URLs but doesn’t know what to use instead

Their complexity makes them a security hazard; their ubiquity makes replacement nigh impossible.

Article intro image

Enlarge / This is how a Chrome 57 displays https://www.xn--80ak6aa92e.com/. Note the https://www.apple.com in the address bar.

Uniform Resource Locators (URLs), the online addresses that make up such an important part of the Web and browsers we use, are problematic things. Their complex structure is routinely exploited by bad actors who create phishing sites that superficially appear to be legitimate but are in fact malicious. Sometimes the tricks are as simple as creating a long domain name that's too wide to be shown in a mobile browser; other times, such as in the above picture, more nefarious techniques are used.

It's for this reason that a number of Chrome developers want to come up with something new. But what that new thing should be is harder to say.

Browsers are already taking a number of steps to try to tame URLs and make them less prone to malicious use. Chrome's use of "Not Secure" labels instead of showing the protocol name (http or https) replaces a piece of jargon with something that anyone can understand. Most browsers these days use color to highlight the actual domain name (printed in black type) from the rest of the URL (printed in grey type); Apple's Safari goes a step further, with its address bar suppressing the entire URL except for the domain name, revealing the full text only when the address box is clicked. Microsoft's Edge (and before it, Internet Explorer) dropped support for URLs with embedded usernames and passwords, because their legitimate uses were overwhelmed by malicious ones.

Read 3 remaining paragraphs | Comments