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?
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.
Why don't I just serve https only?
The main reasons are the default behavior of browsers and backward compatibility.
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.
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.
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.
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.
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/
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.
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.
I use http in addition to https for two purposes:
