Correct Implementation of HSTS and HTTPS - Avoiding a "Bad Time"

[engine]

In a short twitter discussion, Matt Cutts and Gary Illyes discussed the importance of the correct implementation of HSTS when your site uses HTTPS.

HSTS = HTTP Strict Transport Security

If incorrectly implemented,, according to Matt Cutts, your site is "going to have a bad time."

[twitter.com...]

[en.wikipedia.org...]

[goodroi]

I really wish they would/could slowly ease the online world into proper web security. Most webmasters don't know what https is and I would bet many on this forum don't even know there are different types of https. Now we are going to bring up HSTS and really overwhelm our clients. If you aren't well informed on this, get someone that is to do it for you because those guys are correct and you will have a bad day.

[Leosghost]

Most webmasters don't know what https is and I would bet many on this forum don't even know there are different types of https

HSTS is not a "different type of https"..

[en.wikipedia.org...]

[Johan007]

If you are wordpress user I have an excellent article for HSTS implementation for https that I will be following when I get round to adding https on my content site.
[thomasgriffin.io...]

[goodroi]

Sorry if you are confused, I wasn't talking about HSTS. I was referring to the different SSL certificates options for HTTPS

[Leosghost]

I'm not confused..You said different types of HTTPS..You didn't mention SSL certs..

You did however mention HSTS..
Most webmasters on this forum would certainly know that there are different types of SSL cert ( the differences between the types of SSL certs have been discussed here hundreds of times ) , plus most webmasters would have had to be asleep not to have noticed the different colours and icons that the different SSL certs give in their browser address bars..

Different types of SSL certs have existed for many years now..
Installation of the different types of SSL certs is not at all difficult..cpanel and WHM have an icon and an install SSL certs "wizard" for those who run those graphical server config interfaces..

Matt and Gary did not mention SSL certs at all in their conversation..

You seem to be the one who did not know ( or was confused about ) the difference between HTTPS and SSL certs..

[Leosghost]

BTW..re

I really wish they would/could slowly ease the online world into proper web security

If by "proper" you mean completely secure..HTTPS is not completely secure..your ISP ( or anyone with the possibility to put listening equipment at your ISP ) can intercept HTTPS..
Then we have "compromised certs" ..and compromised cert authorities..
Also Certs with insufficient hash algos ( breakable ones ) ..Which is why Mozilla ( and others ) give warnings about SHA1 certs..
Some background "well informed" reading for you..
[eff.org...]
[blog.mozilla.org...]
There is a lot more..right here on WebmasterWorld..many of us "members", do, in fact know, what we are talking about..

You might also find it usefull to get up to speed and well informed to search for "mozilla warning over certs"

The link provided above by Johann007 is also a good guide to HSTS in wordpress..although IMO ( and that of many ) If you are running wordpress, you'll probably be too busy trying to keep it secure from expolits and hackers..;)

[Leosghost]

I would also draw your attention to the paragraph marked "Limitations" here
[en.wikipedia.org...]
and also the paragraph marked "Limitations" here
[en.wikipedia.org...]
Following the links on those pages about TLS and SSL makes for some nice "techy" reading too ;)

I'd also recommend reading this ( very nicely written example of SSL "stripping" / MITM )
[greyhatsspeak.blogspot.in...]
HSTS use stops almost all MITM..
But again the HSTS "limitations" paragraph points out that "1st time visits" are not protected..

BTW..If you go exploring the other articles ( about HTTPS etc ) on the "greyhat" site..use the nav links in the sidebar..not the links in the text.. the text links lead to the now defunct dotcom (now "parked" ) version of the site ..

[goodroi]

Thou doth protest too much, methinks :)

I do appreciate you sharing with the community useful information about web security.

[Leosghost]

Thou doth protest too much, methinks :)

Not protesting too much ..about what would I be protesting ?..
as I said ..

I'm not confused..You said different types of HTTPS..You didn't mention SSL certs..

You did however mention HSTS..

I have made many posts here in the last 10 years on the subject of security ( both specific and in general )..and SSL certs..and HTTPS..

I'm not an expert..and I would not claim to be , nor would I try to infer that I was..compared to "members"..

I have suggested publicly in the past here at WebmasterWorld that we should have a dedicated forum to deal with security matters..
How to protect sites / servers against intruders, "sanitize input", even secure one's personal computer etc ) and also a specific forum, or an "alert system" to publicise "zero day" and "exploit" warnings which many members who only visit specific areas of WebmasterWorld might otherwise miss..

There are many members ( despite your doubts expressed in your first post as to their knowledge and competence in such matters ) here who know a great deal about web security, website security, PC security, Server security, Browser security, plugins security etc etc ( and offline ) security..

Glad to have helped you ( and anyone else ), who was "confused" on the subjects of, and the differences between HSTS, HTTP,SSL/TLS etc .. to learn some things..:)

[engine]

Out of interest, I polled a few webmasters before I posted this info and they did not realise the importance, nor the detail involved.

All of them will be educated by the information in this thread.

[Dymero]

As I learned this weekend, if you have HSTS set to include subdomains, make sure your subdomains are actually using a certificate or Chrome will not let you access them.

[robzilla]

You are going to have a "bad time" with anything you implement incorrectly, whether that's HSTS, robots.txt, error codes, input sanitization, or whatever. HSTS is one of those more advanced (and still fairly obscure) features that you don't just slap on a site; you really need to think that one through, and understand the consequences.

It's worth quoting the full "bad time" tweet from Cutts:

HSTS implies "*always* use HTTPS."

If your website doesn't serve *only* HTTPS, you're going to have a bad time.

[twitter.com...]

Furthermore, it's important to know that HSTS is not easy to reverse, so a warning is indeed in order.

[IanCP]

My only experience of using HTTPS sites, is the recurring annoyance of "invalid" certificates, and the more common "insecure content".

The latter all too often comes down to some content being drawn from HTTP servers. e.g. images...

If you intend using HTTPS, then please serve everything from that server. As to why at least one recipe site uses HTTPS will remain one of life's eternal mysteries.

[Xpat]

I don't think you really meant to say everything must come from the same server. I serve dynamic content from my own server with my own certificate. On the same page, I serve static content from a CDN with a different certificate and obviously from another server. I have HSTS set up on my own server, not sure about the CDN. I don't think there's anything wrong with this setup, but I'm willing to be educated if I have this wrong.

[bill]

What's the advantage of enabling HSTS over just using Apache's mod_rewrite?

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

[robzilla]

What's the advantage of enabling HSTS over just using Apache's mod_rewrite?

An HTTP redirect will still expose the initial request in unencrypted form, including any cookie data. You need the redirect because not all browsers and bots use HSTS, or they may not yet know about your use of HSTS, so I would say the two are complimentary. As with cookies, an HSTS header sets a max-age variable that is remembered by the browser, and possibly even shared(!) among different browsers in so-called preload lists [hstspreload.appspot.com], though I'm not sure this is the current practice. The browser will then automatically convert all HTTP requests to HTTPS, circumventing that redirect and thereby avoiding the exposure of any insecure HTTP requests over the network.

[IanCP]

As I said earlier

As to why at least one recipe site uses HTTPS will remain one of life's eternal mysteries.

Immediately after posting that I resumed my Google search for "Anderson Plugs", well known in 4WD, Caravan, Marine environments.

Yep, on the first site I get security warnings - from a page detailing basic information, not a shopping cart page.

[robzilla]

As to why at least one recipe site uses HTTPS will remain one of life's eternal mysteries.

It's both a security and a privacy thing, and (especially with HTTP/2) it's the future, so why wait? Also, many recipe sites allow users to register, save recipes, post comments, sign up for newsletters, submit a contact form, or whatever. You usually have to register with an e-mail address (private) and a password (private), and we all know many people use the same password for many services, so it'd be a security risk not to use HTTPS, however small that may be on a recipe site. Or maybe they, like myself, currently implement SPDY to increase performance, which (like HTTP/2) requires a secure connection. Reasons aplenty.

[bill]

Or maybe they, like myself, currently implement SPDY to increase performance, which (like HTTP/2) requires a secure connection

But SPDY is depricated by Goolge in Chrome [webmasterworld.com] from 2016... Looks like if you're going to go through all that effort from now you'd be looking at HTTP/2 instead.

I assume HTTP/2 wouldn't even need HSTS.

[Johan007]

Would the use of HSTS over Apache redirect result in an extra 301 redirect if the initial URL has since been re-written into new URL structure? I am keen to avoid the loss in link weight as a result of unnecessary 301 redirects.

[robzilla]

SPDY will be deprecated eventually, but I wonder if it will be as soon as early 2016. The two most popular web servers (Apache and nginx) don't include support for HTTP/2 yet, and once they do it will probably take a while before HTTP/2 becomes more widespread than SPDY. Prematurely deprecating SPDY is more likely to slow down the web than speed it up.

I assume HTTP/2 wouldn't even need HSTS.

Not by itself, no, but we'll need fallbacks to HTTP/1.1 for perhaps another decade to come.

Would the use of HSTS over Apache redirect...

The two are complementary, not alternatives. HSTS doesn't result in a 301 redirect (the browser just switches protocol and remembers to do so in the future), and you will still need that redirect for bots and browsers that have no support for HSTS or are not yet aware of HSTS on your domain (i.e. you're not on the preload list and/or the browser hasn't yet seen the header for your domain).

[bill]

I thought it quite telling that the developer of the SPDY protocol would announce their dropping of support so early in their own browser. Could we assume that HTTP/2 will be ready for the popular web servers well before that cutoff? Updating Apache is not a trivial update in some cases...or is this something that can be retrofitted to older versions?

[dannyboy]

If you're on a cPanel/WHM server and want spdy implemented with Apache, you'll have to wait a while longer. There's a feature request that discusses it, but they're waiting until Apache implements it directly:
[features.cpanel.net...]

LiteSpeed recently implemented HTTP/2 within their server, so if you have cPanel/WHM, you can implement LiteSpeed to work with Apache. More info here:
[litespeedtech.com...]
[blog.litespeedtech.com...]

This requires the v5 Enterprise edition though (for cPanel support), which comes with a monthly licensing fee. Somewhere around $30+ monthly. They also have a free OpenLiteSpeed version, but I don't know much about it other than it not being an Apache drop-in. Nginx also has spdy support.

One thing about HSTS that I think worth sharing: If you're going to implement it, you may want to considering setting a max-age that's not too high. Some sites have code examples setting it to several days, several weeks, or even half a year or one year. It's easy to gloss over this and just copy and paste, but it's a big deal. Until you're sure that you're going to want to stick with it, it's safer to set it to several hours (or maybe even one hour) and then go long term if you know your HTTPS setup is satisfactory.

I've tried HSTS and I had some difficultly with iOS mobile Safari loading a site. It might have been something else entirely (likely) and I'm wrongly blaming the config. Just make sure you test in various devices with a very low max-age setting (a few minutes) and take your time to make sure you don't blow yourself up.

If you ever find that you need to reverse/disable HSTS for your return visitors, you'll have to set the max-age to 0, as explained here in the spec:
[tools.ietf.org...]

A max-age value of zero (i.e., "max-age=0") signals the UA to cease regarding the host as a Known HSTS Host, including the includeSubDomains directive (if asserted for that HSTS Host). See also Section 8.1 ("Strict-Transport-Security Response Header Field Processing").

As for the preload list, you have to specify "preload" within your header, as shown here:
[hstspreload.appspot.com...]

I assume, this is to prevent impetuous folks from shooting themselves in the foot with faulty HSTS. Once you get on the preload list, it can be hard to get off. You'll only want to be on preload if you absolutely know what you're doing and even then, you may want to reconsider not (never?) doing it.