112

I am setting up a new webserver. In addition to TLS/HTTPS, I'm considering implementing Strict-Transport-Security and other HTTPS-enforcement mechanisms.

These all seem to be based on the assumption that I am serving http://www.example.com in addition to https://www.example.com. Why don't I just serve HTTPS only? That is, is there a security-based reason to serve HTTP -- for example, could someone spoof http://www.example.com if I don't set up HSTS?

jjmontes
  • 206
  • 1
  • 7
lofidevops
  • 3,550
  • 6
  • 23
  • 32
  • 8
    non browsers can have a lot more trouble fetching content, if that's a concern. Sites like craigslist thrive on mashups, for example. i don't see the harm in leaving some http sections open, for non-human "users"; they don't care about phishing, xss, or privacy, and you don't even need to serve HTML... – dandavis Apr 18 '17 at 22:52
  • 12
    @dandavis - is that really a problem? If Craigslist went to HTTPS only, wouldn't everyone just convert their fetch scripts over to HTTPS? Most HTTP client libraries include HTTPS support. – Johnny Apr 19 '17 at 15:57
  • 11
    How are people supposed to spread FUD about HTTPS being impractical if you run an HTTPS-only site without any problems? Think, man! And what about the poor hackers who want to attack grandmas who haven't heard of HTTPS-everywhere? It's like you're trying to promote a more secure web or something. – Superbest Apr 19 '17 at 19:22
  • @Johnny: not as much infra supports https as http, that's all. it will get better... – dandavis Apr 19 '17 at 20:10
  • 4
    @dandavis That's something that puzzles me... all major browser should start trying https *before* http... this would solve a sh*tload of security problems... – Bakuriu Apr 22 '17 at 07:32

6 Answers6

161

For usability reasons you need to offer a redirect to HTTPS from all HTTP URL:s. Otherwise first time visitors who simply enter example.com/some/page into the URL bar of the browser will be greeted by a connection error.

Serving the redirect does not make you more vulnerable. Users who don't have your HSTS entry in their browsers will make a HTTP request anyway. Whether or not there is a real service or not on HTTP is irrelevant to a man in the middle.

So you need to run a HTTP server, but it doesn't need to respond with anything but the redirects.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/57580/discussion-on-answer-by-anders-why-should-i-offer-http-in-addition-to-https). – Rory Alsop Apr 23 '17 at 14:31
70

Why don't I just serve https only?

The main reasons are the default behavior of browsers and backward compatibility.

Default behavior

When an end-user (i.e, without knowledge in protocols or security) types the website address in its browser, the browser uses by default HTTP. See this question for more information about why browsers are choosing this behavior.

Thus, it is likely that users will not be able to access your website.

Backward compatibility

It is possible that some users with old systems and old browsers do not support HTTPS or more likely, do not have an up-to-date database of root certificates, or do not support some protocols.

In that case, they either will not be able to access the website or will have a security warning. You need to define whether the security of your end-users is important enough to force HTTPS.

Many websites still listen to HTTP but automatically redirects to HTTPS and ignore users with really old browsers.

could someone spoof http://www.example.com if I don't set up HSTS?

If an attacker wants to spoof http://www.example.com, it needs to take control of the domain or take control of the IP address in some way.

I assume you meant: could an attacker perform a man-in-the-middle attack?

In that case yes, but even with or without HSTS:

  • Without HSTS: An attacker can easily be in the middle of your server and the user, and be active (i.e, modify the content) or passive (i.e., eavesdrop)

  • With HSTS: The first time a user try to visit the site using HTTP, an attacker could force the user to use HTTP. However, the attacker has a limited time window of when it can perform its attack.

What you should do?

Like many websites, you should allow HTTP connections and make you server redirects the user to the HTTPS version. This way you override the default behavior of browsers and ensure your users use the HTTPS version.

Old systems without the proper protocols or root certificates will not be able to access the site (or at least will have a warning), but depending on your user base this should not be an issue.

Conclusion

It will do more harm than good to disable HTTP. It does not really provide more security.

Any security added to protect a resource is useless if it prevents most of its users from accessing it. If your end-users cannot access your website because their browser default to HTTP and you do not listen for HTTP connections, what is the benefit?

Just perform the HTTP 301 redirection to the HTTPS version.

Related questions

Ronny
  • 1,098
  • 8
  • 12
  • I was referring to the bold "With HSTS" bullet, where the wording suggests that there's less security if the server serves a redirect from HTTP to HTTPS. – Ben Voigt Apr 18 '17 at 16:32
  • @BenVoigt Oh ok I see. I removed the "If you serve HTTP" to avoid a misunderstanding. Thanks – Ronny Apr 18 '17 at 16:46
  • 2
    In addition, some users might not be able to access `https` sites. For instance, China has previously been blocking all https traffic to Wikimedia projects. – leo Apr 19 '17 at 10:46
  • Just a correction for the choice of word: The user does not enter a "URL", but a "web address". (There is no such thing as a default scheme/protocol.) – Oskar Skog Apr 19 '17 at 16:33
  • @OskarSkog I changed to "website address", thanks. – Ronny Apr 20 '17 at 00:10
  • 1
    Note that for "With HSTS", preloaded HSTS actually will protect even first-time visitors to your site from MITM attacks. – Ajedi32 Apr 20 '17 at 14:52
20

The up-voted answers are very good. You'll sacrifice usability without a major impact on security if you completely shut off HTTP.

However, you can mitigate that with the HSTS Preload option. Preloading your website means you register your domain with the browser vendors and they'll hard-code their browsers to visit your website via HTTPS only. That means if a user attempts to access your website over HTTP the browser will change the request to HTTPS. They user doesn't need to first get the HSTS header before being secure. They will always connect to you over a secure channel.

Now this doesn't protect users who are using browsers that haven't updated their list of HTTPS only websites. Even when using preloading I recommend not shutting off HTTP for the few people who are using old or un-updated browsers.

But beware, preloading is permanent! It is extremely difficult to get off the preload list.

To get on the preload list: https://hstspreload.org/

Taul
  • 549
  • 1
  • 3
  • 11
  • What problem would be solved by getting off the preload list? I mean, why would anyone want to? (I'm asking a technical question; not rhetorical. My understanding is that they would only want off if they decided to *stop* serving HTTPS for some reason—right?) – Wildcard Apr 20 '17 at 22:51
  • 2
    @Wildcard that is correct. One use case that I could think of is if a domain was registered by person X they let it lapse or otherwise transferred the domain to person Y. Now person Y is forced to use https even though they might not want to for whatever reason like cost, technical limitations with their drag and drop website creator, etc. – Erik Apr 21 '17 at 21:03
  • 1
    @Erik, thanks. From a very long term design perspective, then, I suspect that HSTS preload is permanent by *deliberate choice* —with the eventual end goal of *fully* deprecating http in practice, so that popular browsers will require you to go through "advanced settings" menus even to enable it. At least, we can dream. :) – Wildcard Apr 21 '17 at 21:20
  • 1
    @Wildcard I agree that is probably the goal. I wonder which will happen first internet wide though IPv6 by default or https only? ;) Both are needed but are an uphill battle...... – Erik Apr 21 '17 at 22:11
  • 1
    Scott Hemle has some great info on this. Please read his blog page regarding this: https://hpkp.scotthelme.co.uk/death-by-copy-paste/ In short, Scott gives three reasons. 1) not considering the effects on all sub-domains you manage 2) not considering the effects on all sub-domains that you allow 3rd parties to manage. 3) copy/pasting header configs to include preloading (and then somebody registers your site with or without your permission). – Taul Apr 24 '17 at 19:21
5

You don't have to.

Some older browsers and operating systems (these usually go hand-in-hand) do not have newer certificate root authorities, but they usually don't support newer HTTPS standards either, so nothing really is lost.

You may have a device which doesn't support HTTPS, custom script, etc.

No one can spoof HTTP, because the DNS record belongs to you and the A record points to your specific IP address (in a perfect world).

You do it just to maintain compatibility, that's it.

TRiG
  • 609
  • 5
  • 14
Root
  • 93
  • 4
  • 10
    "No one can't spoof http" — Do you mean "No one can" or "Everyone can"? "the DNS record belongs to you and the a record points to your specific IP address" — By that reasoning, man-in-the-middle attacks never happen, so there's no need for certificate authorities and chain of trust. – jwodder Apr 18 '17 at 14:09
  • 1
    "No one can spoof http, because the DNS record belongs to you" — True. Unless someone spoofs the DNS entry in which case it can be spoofed. – DaveTheMinion Apr 23 '17 at 02:59
3

You should support HTTP only to support backward compatibility. And Make sure that you do proper redirection in the back end server to HTTPS. The best way to implement this is provide the HTTP support only to your home page or any page which do not have sensitive information. You must not support HTTP requests to pages where user can access after the Authentication.

Even if there are devices(IoT) are accessing your server's sensitive data, you must force them to use TLS ( many current devices can store your certificate and create TLS connection). Keep in mind the SSL versions prior to 3.0 do have many vulnerabilities such as poodlebug etc.. Hence, disable all previous version from your Web server and allow only > TLS 1.1.

It is good that you implement the HSTS. I recommend you to take a look at feasibility of implementing HPKP to your site as well.

user3496510
  • 1,257
  • 2
  • 12
  • 26
0

I use http in addition to https for two purposes:

  1. Make the http redirect to the https web site. This is for if someone types in the name of your site into the browser.
  2. I create a separate website for http that is for if someone tries to access the website without using the dot com name. (A real user is not going to do this.) This web site will show a simple Coming Soon message. It will also append their IP address to the IP Tables deny list to permanently ban that IP from the server. This stops slows down hackers that are using masscan. (I found masscan by storing the user agent strings of all the IPs I was blocking to prove to another programmer that it was not google scanning, but in fact, foreign hackers doing the IP scanning looking for web servers to try to hack).
Russell Hankins
  • 105
  • 2