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:
- 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.
- 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 including options to default all or user-typed requests to HTTPS. For some sites, like 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
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. View more posts