8

I'm wondering if it makes sense to enable HSTS on a site that is served over HTTPS as well as over HTTP.

What I mean is to add HSTS-Header if the site is accessed over HTTPS. But there is no redirection from HTTP to HTTPS. The Server will also serve the website over HTTP (without HSTS headers of course).

My goals:

  • Allow users with a broken HTTPS (blocked Port 443 or using proxies without HTTPS support etc.), to view my website using simple HTTP.
  • Allow users with security in mind to access my website over HTTPS with best possible security (including HSTS).

The idea is that a user with broken HTTPS will never see the HSTS header while users accessing my website over HTTPS one time will be forced to use HTTPS in future.

Improve this question
8
  • And what about users who visit your site over http and never get to learn about https version?
    – Cthulhu
    Oct 23, 2015 at 13:31
  • Welcome. While you seem to understand HSTS usage, I do not think your question fits to this webiste. Also, if you exclude redirection or similar methods I do not understand how you are going to serve your web application over HTTP and HTTPS in the same time
    – user45139
    Oct 23, 2015 at 13:32
  • @Cthulhu: Yes, that is an important point. Showing an hint on the website for http user would be one possibility. Even though this is no perfect solution.
    – André
    Oct 23, 2015 at 13:44
  • 2
    @Begueradj I'm not sure if I understand your question correctly. Serving a website over HTTP and HTTPS is simple possible. A quick test shows me that both security.stackexchange.com and security.stackexchange.com works. I would achieve this by adding multiple VirtualHost directives to my apache configuration pointing to the same DocumentRoot.
    – André
    Oct 23, 2015 at 14:15
  • 2
    I have done precisely this for a site I built with a massive legacy browser usage that doesn't support key lengths of the one issued. As a workaround I loaded an empty file from /hsts as a script over a secure connection on the insecure page, to upgrade HTTP users (since the header would have been ignored otherwise). Legacy users simply fail to load the file over the new HTTPS
    – Lewis Goddard
    Oct 23, 2015 at 22:37

3 Answers 3

Reset to default
14

HSTS headers sent over HTTP are ignored by specification compliant browsers - this is to prevent a man-in-the-middle from causing visitors to be unable to access a non-HTTPS website by setting a HSTS rule in the browser. (see RFC 6797)

Therefore, you can safely, although technically incorrectly, serve HSTS headers to all your users, and provide the same pages over HTTP and HTTPS, and deliberately not redirect from insecure to secure pages.

This will have the effect that visitors who visit your HTTPS version will be forced back to it upon future visits (for the duration of the header, at least), and visitors who deliberately visit your HTTP version will stay on that. If they follow a link to the HTTPS version at any point, they will be forced to HTTPS in the future.

As to whether it makes sense, it depends on your objectives, and on your visitors - do you have many visitors from broken proxies? Do you provide information which could be incriminating on some pages?

Personally, I'd just serve the secure version, and have an enforced redirect from the insecure one, especially since search engines seem to be moving towards preferring secure sites.

Improve this answer
7
  • This is harder than it looks. If the website contains any internal links, those will have to be HTTP-only, or else HTTP users will be forced onto HTTPS permanently. That in turn hurts SEO because you effectively have two separate websites. IMHO this is far too fragile to rely on in any consumer-facing website. End users do not want to hear about the HSTS header, or the broken proxy, or anything. They just want to go on your website and do things.
    – Kevin
    Oct 23, 2015 at 15:26
  • 2
    @Kevin Ideally you'd just make the links protocol relative. (E.g. //mysite.com/page)
    – Ajedi32
    Oct 23, 2015 at 15:45
  • 1
    @Kevin Yes - this does depend on the site construction to some extent. If you only every use relative links (some CMS behave in this way), you'll be fine, but one mistake, and your HTTP-only users are forced to HTTPS for future visits. The other issue is third party sites: they'll have to pick one or another to link to. I would agree that it's a very fragile method though, and wouldn't recommend it.
    – Matthew
    Oct 23, 2015 at 15:46
  • @Ajedi32 Doesn't handle the third party links issue though - that would give your users whatever the third party site used, assuming that the site author didn't just copy-paste whichever version they had been looking at for their link.
    – Matthew
    Oct 23, 2015 at 15:48
  • 1
    @Matthew Huh? If I write //thirdparty.com/page.html as the link, that will send users to http://thirdparty.com/page.html if they're visiting my site via http, and https://thirdparty.com/page.html if they're visiting my site via https. Isn't that exactly the behavior you want?
    – Ajedi32
    Oct 23, 2015 at 16:56
8

The HSTS header doesn't have an effect while the site is accessed over HTTP.

The goal of HSTS is to force the browser to load the site over HTTPS, having the option of viewing it over HTTP is counter-intuitive.

Improve this answer
2
  • OK, you are right. This is no straight-forward configuration. And the idea of HSTS is that a website is only accessible over HTTPS. However disabling HTTP access is not always useful
    – André
    Oct 23, 2015 at 14:24
  • Well, after the HSTS header is received, the user no longer has the option of viewing the site over HTTP. This does serve the stated goal though of allowing "users with a broken HTTPS (blocked Port 443 or using proxies without HTTPS support etc.), to view my website using simple HTTP"
    – Ajedi32
    Oct 23, 2015 at 15:40
2

I'm wondering if it makes sense to enable HSTS on a site that is served over HTTPS as well as over HTTP.

I'm not entirely certain for HSTS but I think so.

(The idea itself is sound. It is similar to what "Opportunistic Encryption" has in mind: make the attacker work harder by using at least some amount of crypto for at least some connections.)

The RFC's abstract says this:

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.

And the "and/or" bit of the sentence seems important here.

So what you can do via HSTS is declare something like: This site is HTTPS all the way. This site will work for you even if your firewall blocks all connections to port 80. And as an afterthought: Should there be a plain HTTP link left anywhere around here, then that's a mistake, please quietly upgrade that to HTTPS.

And this silent-upgrade-xor-failure bit would save you from a scenario they give here: (section 2.3.1.3)

Even if the site's developers carefully scrutinize their login page for "mixed content", a single insecure embedding anywhere on the overall site compromises the security of their login page because an attacker can script (i.e., control) the login page by injecting code (e.g., a script) into another, insecurely loaded, site page.

And while the server is expected to redirect the client to HTTPS (section 7.2):

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect,

...this is a SHOULD and not a MUST.

So, in summary: yes, what you're asking should be both a possible and a legitimate use of HSTS.

Another thing: if you wish to support laptop users who may use both the HTTPS version of your site (e.g. from home) and the plain HTTP version of your site (e.g. from their office WIFI), then you will have to set the HSTS timeout low enough. (A few minutes maybe.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .