Google To Enforce HTTPS Connections For 45 TLDs

By Lucian Armasu
published

Google announced that 45 of the top-level domains (TLDs) it recently purchased, including .dev, .app, .eat, and so on, will enforce HTTPS security, guaranteeing that all connections to sites using those TLDs will be over encrypted channels.

What Is HSTS?

HTTP Strict Transport Security (HSTS) is a web security policy that ensures a user will always connect via an encrypted HTTPS channel to a website after the initial connection to that site. If the user then tries to connect to http://gmail.com, for example, the browser will automatically switch to https://gmail.com before sending out the request to Google.

Once the HSTS response header is received by the browser on the first connection, the user can no longer connect to that site using HTTP, which means any downgrade attacks (from HTTPS to HTTP) will also be prevented.

However, because HSTS still normally needs that first connection before it can be enabled in the browser for a given website, a small window of opportunity for an attacker can still exist to launch a man-in-the-middle attack against someone visiting a certain website.

This can be fixed for certain websites, if they are included in the HSTS preload list in the major browsers. Then, the browsers will be able to enforce HTTPS encryption from the very first connection.

HTTPS Enforcement For Entire Domains

Not just domains and subdomains can be included in the HSTS preload lists of a browser, but entire TLDs, too. For instance, if the .com TLD would be included in this list, then nobody would be able to connect to any existing .com website unless they were doing it over HTTPS.

Considering many websites still haven’t even adopted HTTPS yet, let alone mandated the use of HTTPS for their visitors, that’s not possible, at least for the time being. However, this can work for new TLDs, such as .dev and .app, and this is what Google is announcing today.

Google, which has recently purchased 45 TLDs, is now able to enforce HTTPS for those 45 TLDs. As the company has recently become a domain registrar as well, others will soon be able register domains with one of those secure-by-default Google-owned TLDs.

Google also hopes that all owners of other new TLDs will enable HSTS by default, which would ensure that all new websites using such TLDs will always connect via HTTPS.

Lucian Armasu
Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
Topics
Google
Security
6 Comments Comment from the forums
  • Rookie_MIB
    Well, that's just plain dumb (wanting EVERY website to use HTTPS). While certainly there are websites out there which should require encryption of data, like any site that routinely stores account information of any type*, wanting it for EVERY site is unnecessary.

    My personal website? Not needed. My business website (which exists for basic information only)? Not needed. Why would I want to go through the extra expense to pay for security certificates which I don't need! Yes, I could self-sign, but then almost every browser would throw up flags.

    If the browsers would scale that back and allow for a more relaxed handling of security certs, then I'd consider self-signing and going https. Until then? Nope.
    Reply
  • derekullo
    https://letsencrypt.org/

    Is quite literally free.

    What are you talking about?
    Reply
  • Kewlx25
    20219769 said:
    Well, that's just plain dumb (wanting EVERY website to use HTTPS). While certainly there are websites out there which should require encryption of data, like any site that routinely stores account information of any type*, wanting it for EVERY site is unnecessary.

    My personal website? Not needed. My business website (which exists for basic information only)? Not needed. Why would I want to go through the extra expense to pay for security certificates which I don't need! Yes, I could self-sign, but then almost every browser would throw up flags.

    If the browsers would scale that back and allow for a more relaxed handling of security certs, then I'd consider self-signing and going https. Until then? Nope.

    The bad guys can leverage the fact that you use HTTP to make browsers use HTTP when it should be using HTTPS. The fact that HTTP exists means downgrade attacks exist. Get rid of HTTP and get rid of downgrade attacks.

    There is no safe way to automatically detect when HTTPS should be used.
    Reply
  • mikeytinks
    I don't know why browsers don't use https by default in the first place? And then downgrade if no response and try again on http?
    Reply
  • hellwig
    Remember before Web 2.0 when many pages were just static collections of data. If there was some sort of read-only interface to a website that didn't need to be encrypted, that could be implemented along-side of https. Remember RSS? of course, RSS was just an additional data file retrieved via HTTP, not itself an actual protocol.

    HTTP stands for "hyper text transport protocol". Somehow, this got turned into the default protocol for everything on the internet. So instead of visiting an HTTP site to retrieve static content, now you got to an HTTP site and it might ask you for your credit card information. Someone said "this is insecure" and added secure-socket-layer (SSL) to the protocol and gave us HTTPS. In restrospect, perhaps a different protocol for truly secure bi-directional communication should have been created? HTTPS should NEVER have been allowed to fall-back to HTTP, but because it was an addition to HTTP, not a different protocol, it was insecure from the start. Now we have an entire internet barely able to handle security.

    And before LetsEncrypt, the process to even setup HTTPS was expensive and complex. Luckily that's been eliminated, but the HTTP:HTTPS cross-dependencies will basically mean a lot of insecurity until HTTP goes away or a viable successor just replaces the whole thing.
    Reply
  • Kewlx25
    20222197 said:
    I don't know why browsers don't use https by default in the first place? And then downgrade if no response and try again on http?

    Waiting for the response takes upwards of 30 seconds. Most people don't want to wait 30 seconds. What if a "bad guy" is blocking port 443 between you and the site you're trying to connect to. Then when you can't connect and downgrade and now you're connecting to your bank over HTTP and now they have access to your account.

    HTTP needs to die.
    Reply