Google’s Push to Close a Major Encrypted Web Loophole
Credit to Author: Lily Hay Newman| Date: Thu, 13 Jun 2019 14:26:02 +0000
The internet-wide push to encrypt more web traffic has resulted in a wave of safer, snoop-proof connections. The next challenge, though, is completing that transition from using a mixture of unencrypted HTTP and protected HTTPS to requiring that baseline protection everywhere. And over the past year, Google has been publicly offering a simple and straightforward way for websites to eliminate these subtle weak spots.
When HTTPS encryption was still a novelty, web developers needed to create features that would allow HTTPS and HTTP pages to interoperate, because the majority of sites were still unencrypted. So HTTPS architects built mechanisms to upgrade or downgrade browsing sessions between HTTP and HTTPS when needed, so that people wouldn't be blocked from using certain sites completely. But as HTTPS has proliferated, it's finally time to bypass or otherwise eliminate those intermediary features. Otherwise, pages still served over HTTP, like those redirect pages, will continue to be at risk of interception or manipulation.
"It's nice to see Google demonstrate that it's a viable default for top-level domains."
Josh Aas, Let's Encrypt
So Google has built HTTPS protection directly into a handful of top-level domains—the suffixes at the end of a URL like ".com." Google added its internal .google top-level domain to the preload list in 2015 as a sort of pilot, and in 2017 the company started using the idea more extensively with its privately run suffixes ".foo" and ".dev." But in May 2018, Google launched public registrations of ".app," opening up automatic, preloaded encryption to anyone that wanted it. In February of this year, it opened up .dev to the public as well.
Which means that today, when you register a site through Google that uses ".app," ".dev," or ".page," that page and any others you build off it are automatically added to a list that all mainstream browsers, including Chrome, Safari, Edge, Firefox, and Opera, check when they're setting up encrypted web connections. It's called the HTTPS Strict Transport Security preload list, or HSTS, and browsers use it to know which sites should only load as encrypted HTTPS automatically, rather than falling back to unencrypted HTTP in some circumstances. In short, it fully automates what can otherwise be a tricky scheme to set up.
"Web security stuff is complicated, and not every end user or even every site creator understands all of the complexities," says Ben Fried, Google's chief information officer. "The thing that I like about using these new top-level domains in this way is it dramatically decreases the burden on each site creator to get to the best practices. Nothing has to be done, because every subdomain in that top-level domain is HTTPS only and the browser won’t even try to access it any other way."
The breakthrough moment came from engineer Ben McIlwain's realization that an entire top-level domain could go on the preload list. "Internally it took off from there," Fried says. "We realized these are two things that had developed independently that all of a sudden were way more powerful when combined.”
Site developers who know about the HSTS preload list can add URLs to it individually rather than using an umbrella top-level domain like Google's, but Fried points out that this is a more labor-intensive process that also involves waiting for browsers to get new, updated versions of the preload list. By proactively adding top-level domains to the list, browsers will automatically recognize every URL built off them as requiring automatic encrypted connections.
Google says that it has millions of sites registered on its top-level domains so far, including hundreds of thousands on .app alone.
"The web started off with no data transport security by default, and that's an entrenched legacy that we need to move away from as quickly as possible," says Josh Aas, who runs the nonprofit HTTPS certificate authority Let's Encrypt. "Normally browsers have an initial interaction with a site via plain HTTP to find out whether or not the site wants HTTPS. HSTS preloading makes that initial nonsecure interaction unnecessary. It's nice to see Google demonstrate that it's a viable default for top-level domains."
As with all Google expansions, the move into acting as a top-level domain registrar only further expands Google's entrenched—and influential—position on the web, for better or worse. But when it comes to promoting HSTS preloads, though, the move seems to be for the better. Nifty suffixes like .app and .dev don't solve every internet security issue, but they offer an easy way for site developers to check one crucial thing off the list.
Fried says that if people happen upon Google's top-level domains and get the security benefits without even realizing it, well, that's the whole idea.