HTTPS Goofs: Forgetting the Bare Domain

As I mentioned, the top failure of HTTPS is failing to use it, and that’s particularly common in in-bound links sent via email, in newsletters, and the like.

Unfortunately, there’s another common case, whereby the user simply types your bare domain name (example.com) in the browser’s address bar without specifying https:// first.

For decades, many server operators simply had a HTTP listener sitting at that bare domain, redirecting http://example.com to https://www.example.com, changing from insecure HTTP to secure HTTPS and redirecting from the apex (base) domain to the www subdomain.

However, providing HTTPS support on your www subdomain isn’t really enough, you must also support HTTPS on your apex domain. Unfortunately, several major domains, including delta.com and royalcaribbean.com do not have HTTPS support for the apex domain, only the www subdomain. This shortcoming causes two problems:

  1. It means you cannot meet the submission requirements to HSTS-Preload your domain. HSTS preloading ensures that non-secure requests are never sent, protecting your site from a variety of attacks.
  2. Users who try to visit your bare domain over HTTPS will have a poor experience.

This second problem is only getting more common.

Browsers are working hard to shift all traffic over to HTTPS, adding new features to default to HTTPS for user-typed URLs (or optionally even all URLs). For some sites, like https://delta.com, the attempt to navigate to HTTPS on the apex domain will very slowly time out:

…while for other sites on CDNs like Akamai (who do not seem to support HTTPS for free), the user gets a baffling and scary error message because the CDN returns a generic certificate that does not match the target site:

It’s frustrating to me that Akamai even offers a “shoot self in foot” option for their customers when their competitors like Cloudflare give HTTPS away, even to sites on their free tier who don’t pay them anything.

Ideally, sites and CDNs will correct their misconfigurations, helping keep users secure and avoiding confusing errors.

On the browser developer side, it’s kinda fun to brainstorm what the browser might do here, although I haven’t seen any great ideas yet. For example, as I noted back in 2017, the browser used to include a “magic” feature whereby if user went to https://www.example.com but the cert only contained example.com, the user would be silently redirected to https://example.com to avoid a certificate error. You could imagine that the browser could introduce a similar feature here, or we could ship with a list of broken sites like Delta and Royal Caribbean and help the user recover from the site’s configuration error. Unfortunately, most of these approaches don’t meet a cost/benefit bar, so they remain unimplemented.

Please ensure that your apex domain loads properly over HTTPS!

-Eric

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, working on Office, IE, Edge, and Web Protection. My words are my own, I do not speak for any other entity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: