New .Gov Domains to Force HTTPS: HSTS Preloading Will Be Enabled Starting Sept. 1 – Security Boulevard

New .Gov Domains to Force HTTPS: HSTS Preloading Will Be Enabled Starting Sept. 1  Security Boulevard

In a move that aims to make all U.S. federal, state and county websites more secure, the General Services Administration’s DotGov Program announces that new government domains will be added to the HSTS preload list starting this fall as part of a larger move toward the eventual full .gov migration to HTTPS

What’s massive, bloated, and slow to change?

If your answer is “the U.S. government,” then you’d be correct. I say this because it’s 2020, and we’re still watching the government (slowly) add SSL/TLS certificates to their websites to ensure secure connections. This is even after the Obama administration issued an executive order in 2015 (M-15-13) that compelled them to do so.

Heck, my predecessor, Patrick Nohe, even started a White House petition to compel the General Services Administration (GSA) to add the .gov TLD to the global browser HSTS preload list (although that didn’t get enough votes — most likely because not enough people understood the importance of what he was trying to accomplish).

Needless to say, this migration to HTTPS is happening a lot more slowly than we’d like. But there is some good news that we’re happy to share: The DotGov Program has announced their intention to add new .gov domains to the HSTS preload list starting Sept. 1, 2020.  This means that they’re showing their commitment to serving all of their websites via the secure HTTPS protocol (eventually).

So, what does HSTS preloading mean for government website users and website security as a whole? And what does it mean for the future of HTTP?

Let’s hash it out.

What Is HSTS Preloading and Why Does It Mean Greater Security for End Users?

Simply put, HSTS — or what’s also known as HTTP Strict Transport Security — is a web security policy that forces a browser to only make secure HTTPS (Hypertext Transfer Protocol Secure) connections with the relevant website. Even if the user types in “http://,” the browser will ignore that and use “https://” anyway.

This is great, right? It means that it’s going to force browsers to use a more secure connection no matter what. However, there’s one small caveat with HSTS: it uses a header to communicate the strict transport security parameter. This means that you’d need to download the header before your browser knows to always connect to the website via HTTPS in the future.

Because the policy communicates this way, it means that there’s a small window of opportunity (before the browser downloads the header) in which hackers could swoop in during that first connection. Although it’s a very narrow attack vector and, with the right tools, a bad guy could eliminate the SSL encryption connection and, ultimately, steal data or phish your users.

However, this is where HSTS preloading saves the day. The HSTS preload list is a set of websites that are hardcoded into browsers to employ strict transport security. What this means is that when someone connects to a website on the HSTS preload list for the first time, the browser already knows that it must connect only using an HTTPS connection, thereby eliminating that small window of opportunity for hackers.

So, by adding government websites to the HSTS preload list, it means that all of the browsers using the list will already know that they can only connect using HTTPS. (Hence why it’s call “HSTS preloading, because you’re preloading the list with those specific domains.)

An additional added benefit of HSTS preloading is that users will experience faster page load speeds because the browsers will no longer require server redirects from HTTP to HTTPS. Sounds like a real win-win, if you ask me.

How Data Transfers Across the Internet Without the Use of HTTPS

But why is HSTS preloading — and using HTTPS in general — really necessary? Let’s take a moment for a quick refresher on how data transmits across the internet for sites that don’t use HTTPS.

Any info that’s sent between two parties (for example, your end users’ web browser and the website they’re connected to) via the internet is sent in plaintext format. This means that any data sent using HTTP can be intercepted and read by anyone — your nosy neighbor Tim, your employer, government entities, or a random (and potentially malicious) hacker.

Not only is this a big privacy issue, but it’s also a security issue that can result in identity theft and a litany of other types of cybercrimes.

HTTPS Secures Data in Transit

In a nutshell, HTTPS is a connection made via the transport layer security, which is a combination of encryption and digital signatures. This type of connection enables the communication channel between the two parties to be encrypted to ensure data transmissions are secure.

According to the DotGov website:

“HTTPS is a key protection for websites and web users. It offers security and privacy when connecting to the web, and provides governments the assurance that what they publish is what is delivered to users. In the last few years, HTTPS has become the default connection type on the web.”

Google’s latest Transparency Report data (as of June 13, 2020) shows that 95% of users connect via HTTPS:

And this is great — 95% of users is the overwhelming majority. But it’s still not at the level that website users need it to be. For a truly secure internet, this number should be at the full 100%. But, hey, we understand that Rome wasn’t built in a day. And considering that the internet was originally built for government use (for scientists and researchers to share data) and not for the personal or commercial use it’s evolved to today, it’s a little understandable why these changes take time.

It’s important to note, however, that while HTTPS only guarantees the integrity of the connection between two parties or systems — it doesn’t guarantee that the system or website that an individual connects to is legitimate. So, you could be securely connected to a website, but HTTPS doesn’t ensure that it’s the real site. This is the difference between being “safe” and being “secure” — it’s also where fake/phishing websites can really ruin your day.

Where SSL/TLS Certificates Come Into Play for Website Security

Using encryption on a website isn’t going to do you any good if you’re connecting to a hacker’s device instead of the legitimate server. However, there is a solution: install a minimum of organization validated (OV) SSL/TLS certificates on your web server. By using an OV (or extended validation) SSL/TLS certificate on your website, you’re ensuring that any data transmitted between users and your website is secure by:

  • Authenticating the web server to the client. This enables clients to verify that they’re actually connecting to a legitimate party because the site and organization that owns it has been validated by a trusted third party (certificate authority [CA]).
  • Using an encryption key to secure the channel. What this does it transmit data via a secure connection so it appears as gibberish to any non-intended parties — this way, anyone outside the channel can’t decrypt and read the data transmitting within it because they don’t have a key.  

Using an SSL/TLS certificate to facilitate an HTTPS connection helps to protect users against eavesdropping and man-in-the-middle (MitM) attacks. But OV/EV SSL takes security a step further by adding identity assurance that validates the identity of the organization, government, or business to whom a website belongs.

Manage Digital Certificates like a Boss

14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.

30,000 Foot Perspective: What This Shift to HTTPS (via HSTS Preloading) Means

For starters, this mass move to HTTPS via HSTS preloading is obviously a great security measure. However, it’s not perfect and still means we have a long way to go. Despite the fact that Google pretty much made HTTPS mandatory for websites to rank several years ago, not all government websites have migrated to HTTPS. For example, the Florida Department of Health website loads via the insecure HTTP connection:

Graphic: A screenshot of the insecure HTTP connection made on the Florida Department of Health website on June 24, 2020.

The same can be said about the New York State Library website:

Graphic: A screenshot of the insecure HTTP connection made on the New York State Library website on June 24, 2020. (It’s using an insecure connection, much like the rest of the New York State Department of Education website.)

Of course, there are still plenty of other government sites that don’t use HTTPS. The silver lining here, though, is that since May 2017, any new federal executive branch .gov domains have been automatically added to the HSTS preload list. Furthermore, since August 2018, they’ve also allowed other newly registered .gov domains to opt-in to this protection.

Now, why they didn’t just make it mandatory for all .gov domains instead of leaving it as an opt in? You’d have to ask them. But at least this move is still a step in the right direction.

Of course, this HSTS preloading initiative isn’t going to be without its struggles. In the DotGov Program’s report “Making .gov More Secure by Default,” they admit that while the HSTS preloading process itself is easy, getting everyone to the table that the change would affect is going to be quite the undertaking:

“Note that we’re announcing an intent to preload the TLD, but not actually preloading it today. If we did that, some government websites that don’t offer HTTPS would become inaccessible to users, and we don’t want to negatively impact services on our way to enhancing them! Actually preloading is a simple step, but getting there will require concerted effort among the federal, state, local and tribal government organizations that use a common resource, but don’t often work together in this area.

With concerted effort, we could preload .gov within a few years.”

Final Thoughts on Adding All Government Domains to HSTS Preload List

The concern here would be that even though 95% of traffic is connecting to websites using HTTPS, it means that there’s still 5% that’s not. Even if you just narrow this down to traffic connecting to government domains, that’s still a lot of people and potentially missed connections if the process isn’t handled properly.

Okay, that’s the bad news — but there is good news. For one, this means that if they take their time, they’ll (hopefully) do it right. (Okay, I know there’s an obvious punchline about government efficiency here, but let’s keep things civil.) Basically, they’ve announced their intention to add all future .gov sites to the HSTS preload list. So, any future sites after that date need to be set up as HTTPS only.

Secondly, this shift to HTTPS via HSTS preloading means that the insecure HTTP protocol is now one step closer to its (inevitable) demise. This move by the DotGov Program to ensure government website users will only be able to connect via secure connections in the future essentially pounding a massive nail into the coffin of HTTP.

All in all, we’re glad to see that DotGov Program has made the public commitment to greater website safety through HSTS preloading. Frankly, it’s been long overdue. However, Uncle Sam is quick to hedge his bet about the progress of the initiative by stating up front that this isn’t going to be a quick move. So, we should prepare ourselves for some bumps along the road ahead.

*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Casey Crane. Read the original post at: https://www.thesslstore.com/blog/gov-domains-to-force-https-hsts-preloading-will-be-enabled-starting-sept-1/