Webcast: How to implement HSTS on your .brand TLD

Webcast: How to implement HSTS on your .brand TLD


Hello, my name is Corey Grant, and I’m from
Neustar’s Registry division. Today I’m going to take you through an overview of HSTS, and
why you should implement HSTS on your dotbrand Top-Level Domain. First we’ll take a look
at what HSTS is, then we’ll look at the benefits to your organization for using HSTS, and then
lastly we’ll take a look at what it takes to implement HSTS on your dotbrand Top-Level
Domain. So, I hope you enjoy, let’s get started. Why are we even talking about HSTS? Well,
because online security is a part of our daily lives, and it’s becoming more challenging
every single day. HSTS isn’t a silver bullet for overcoming all cyber security issues,
but it is a simple and important step we can all take, to make the day-to-day interactions
our customers have with us more secure. Your dotbrand Top-Level Domain can be beneficial
across a wide range of applications, but one that I think many people forget is that you
can use your TLD to differentiate yourself from competitors who don’t have one. Providing
a more secure online environment builds trust, which is one of the most powerful aspects
of branding that there is. So as we go through HSTS in more detail today, please keep in
mind that the small amount of effort involved can be leveraged into a major competitive
advantage for your dotbrand. Of course, the flipside to that is getting it wrong. Those
who drag their feet on digital security for their customers will see a weakening of their
brand – if not outright brand damage. We’ve all seen the evolution of browsers highlighting
non-secure sites. At the top there is the Shopify site, and Google Chrome now tells
us explicitly that this site is not secure, as it is served over HTTP. The Neustar site
at the bottom there is secure, but the browser no longer gives it a green padlock. Instead
it just gets a grey padlock, because Chrome is telling us that security should be standard.
Security on websites and in browsers is evolving quickly, and HSTS is the next evolution. So,
to understand HSTS, we first need to revisit HTTP and HTTPS. HTTP is the original protocol,
which enables us to navigate the web, and for browsers to load websites. Then along
came HTTPS, which most of you will have on your main sites. HTTPS is a secure version
of HTTP, where the main difference is that certificates are required on domains and subdomains,
and traffic is encrypted. This added a layer of security so you can be confident of who
you are dealing with. The next evolution is HSTS, which is an even more secure protocol.
It doesn’t replace HTTPS, but instead forces browsers to use HTTPS every time the browser
requests content from a webserver. And because we need another acronym in our lives, HSTS
stands for ‘HTTP Strict Transport Security’ – and yes, that’s an acronym within an acronym.
So who is involved in HSTS and why are you hearing about it now? HSTS is a protocol that’s
actually been around for quite a few years, but now Google have thrown their weight behind
it. We’ve seen a couple of interviews that we’ve done now with Ben McIlwain from Google,
who provides some great background and reasoning behind HSTS, so if you haven’t seen the latest
video, it is worth checking out on MakeWay.World. Let’s look at a basic diagram of what happens
when a typical user browses the web. They type in ‘example.com’, and the browser says
“Aha, now I request the HTTP version of example.com” because by default, that’s what browsers still
do. Since the webserver for example.com has a secure, HTTPS version, it wants the browser
to request that HTTPS version, so it tells the browser to do just that. So the browser
sends another request for example.com, but this time using HTTPS. And the webserver serves
up the HTTPS version. So, what does HSTS do? Essentially, HSTS forces the browser to request
the HTTPS version of a site from the webserver the first time. So the browser never does
the HTTP step, protecting the user from man-in-the-middle attacks and similar. So, if HTTPS is secure
and your websites already have HTTPS, why do you need HSTS? Firstly, there is a small
speed gain from using HSTS, since the browser will no longer do the initial HTTP request.
But the main reason is security. When that HTTP request is sent, the user is exposed
to man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. By
defaulting to HTTP, the browser leaves the user open to being hijacked on that first
request, every single time. The other issue is that users will see HTTPS in the browser
bar an assume that there is a secure connection that’s being made. Websites are generally
made up of many different elements, such as images and other third-party elements that
might not all be HTTPS. All of the elements might have been HTTPS compliant when you built
the website, but certificates can lapse and other errors can creep in over time. HSTS
protects the user from this, by ensuring only HTTPS content is served. So let’s take a look
at the HSTS preload list. This is a list which is maintained by Google, and used by all the
major browsers. You can submit a single domain or a whole Top-Level Domain to the preload
list. Once your domain or your TLD is approved and added to the preload list, the browser
publishers will add you to the next release. And from then on, the preload list is actually
hard-coded into all the major browsers. There are already 13 TLDs on the HSTS preload list.
Some of these are quite large, including .app, which launched in 2018 and now has over 300,000
domains registered. Each and every one of those domains, owned by hundreds of thousands
of different people, is automatically HSTS compliant. So it certainly hasn’t put people
off buying a .app domain, and you could argue it has boosted the popularity of .app. Several
of those TLDs up there are owned by Google, which shows how committed Google is to HSTS.
Note also .bank and .insurance – both TLDs which are built around a high level of trust.
Now, obviously I haven’t listed every browser available, and there may be some obscure browsers
that are yet to implement HSTS, but all of the major browsers already support HSTS and
have done so for some time. Why should you add your TLD to the preload list? First and
foremost, it is about security. Even before Neustar started promoting HSTS for dotbrand
TLDs, we had multiple banks tell us that they were already preparing for HSTS on their TLDs.
Not only does it enable HSTS, but it means there is no waiting for individual domains
to be rolled out to the hard-coded lists in browsers. Once the TLD is in the preload list,
every new domain from then on is automatically covered. The other big reason is that most
brands only have a small number of domains in their TLD right now, so it’s easier to
put processes in place and add your TLD now rather than later. Those who already have
a large number of domains can still achieve HSTS compliance, but it certainly is easier
if you only have a handful of domains. C) is faster load times and improved search ranking
that it brings. It’s only a minor speed bump, but every little thing counts with SEO. And
D) it forces you into best practice when it comes to security for your web content, which
should help everyone move forward on security just that little bit quicker. “That all sounds
very convincing, Corey” I hear you say, “but what else do I need to consider?” Well the
big one is that you need to ensure that all of the sites on every domain you have in your
TLD need to have full HTTPS compatibility, and be confident that no part of the content
will revert back to HTTP. Because if it does revert to HTTP, then your site won’t load
and the user will get an error. You also need to check your own certificates. So your security
team will already know how to do this, it’s just a matter of making it part of the process
of adding any new domains. You also need to review your third-party elements that make
up your web content such as images, your CDN, single-sign-on etc, and you also need to consider
your redirects – because even if they don’t host any content, your redirects need to be
HTTPS. So, how do you actually implement HSTS on your dotbrand Top-Level Domain? There are
three major steps here. Number one, audit your current domains and their content – and
there are plenty of online tools to help you do that. Number two, make sure you have processes
in place that will prevent current sites – and especially future sites that you haven’t created
yet – from failing to deliver only HTTPS content. Most organizations have processes in place
for creating new websites already, so you should be able to just expand on what’s already
in place to accommodate these security precautions – which of course, would already be in place
in a perfect world. Step three, once you’re confident all of that’s completed, submit
your TLD to the preload list. That’s an easy enough process, with instructions available
on the website shown there on the screen. And that’s it, you’re done! If you only have
a handful of domains in your TLD, now really is the time to do it and it should be quite
straightforward. Your TLD will be compliant with current protocol, and you’ll most likely
have a competitive advantage over your opposition, which they can not match because they don’t
have their own dotbrand TLD. If you have any questions, please reach out using the email
address [email protected] and don’t forget to take a look at MakeWay.World for
more articles, videos, statistics and Showcase items from the world of dotbrands. You can
also follow us on Twitter at @NeustarTLDs. Thanks for joining us. Feel free to reach
out to the Neustar team if you have any questions – we’re always happy to help.

1 thought on “Webcast: How to implement HSTS on your .brand TLD

Leave a Reply

Your email address will not be published. Required fields are marked *