Google’s Chromium team today highlighted some upcoming changes in the current and near-future Chromium versions. Here’s the list:
- Chromium 11: strong random numbers for the web
- Chromium 12: user-specified HSTS preloads and certificate pins
Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts
You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.
It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings.
- Chromium 13: blocking HTTP auth for subresource loads
There’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img> tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.
To resolve this, Google blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. Also added the command line flag switch –allow-cross-origin-auth-prompt in case anyone has legacy apps which require the old behavior.
- Chromium 13: Content-Security-Policy support
Added an initial implementation of Content Security Policy, first introduced in Firefox 4. You can now use X-WebKit-CSP header to experiment with our implementation.
- Chromium 13: built-in certificate pinning and HSTS
As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against sslstrip-type attacks.
The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.
In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority.
This’s an interesting area because it’s hard to know what detail of instruction it’s possible to trick a user into following. It’s also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).
[Source: Chromium blog]