A website I frequent have finally decided to enable TLS to their servers, only not to mandate it as a lot of websites out there do. The maintainer claims that TLS must be optional. Why?

On my own website I have long set up mandated TLS and HSTS with long periods, and the weaker cipher suites are disabled. Plaintext access is guaranteed to be walled out with a HTTP 301 to the TLS-protected version. Does this affect my website negatively?

  • 13
    They may fear, that HSTS will get them into trouble, if ANYTHING goes wrong (i.e. their free CA stops issuing certificates or is removed from browser trust stores due to some issue). With the current TLS ecosystem, you create dependencies to the trusted CAs/the browser vendors. It's currently hard to avoid and worth it, but you can still see this as an problem and not enforcing HTTPS as an solution to stay independed in case something happens.
    – allo
    Commented Apr 2, 2017 at 11:03
  • anyone want to mention the requirement of tls for h2, which is far fast than http1.1. good for you doing hsts, I recently sent my site for the hsts preload list, hopefully I can just disable port 80 all together Commented Apr 2, 2017 at 20:58
  • See this: security.stackexchange.com/questions/53250/…
    – d33tah
    Commented Apr 3, 2017 at 10:23
  • 4
    @gerrit This argument does not stand in front of low-cost and free certificate authorities like Let's Encrypt. Commented Apr 4, 2017 at 18:20
  • 1
    Let's Encrypt does not work with every host, and it isn't as simple as using a better host. I use App Engine which isn't (directly) supported for technical reasons.
    – Carl Smith
    Commented Apr 5, 2017 at 1:09

9 Answers 9


There are several good reasons to use TLS

(and only few marginal reasons not to do so).

  • If the site has any authentication, using HTTP expose for stealing sessions and passwords.
  • Even on static, merely informational sites, using TLS ensures no-one has tampered with the data.

  • Since Google I/O 2014, Google has taken several steps to encourage all sites to use HTTPS:

  • The Mozilla Security Blog has also announced of Deprecating Non-Secure HTTP by making all new features available only to secure websites and gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

There are also several good reasons to enforce TLS

If you already have a widely trusted certificate, why not always use it? Practically all current browsers supports TLS and has root certificates installed. The only compatibility problem I've actually seen in years have been Android devices and Missing intermediate certificate authority as Android only trusts root CAs directly. This can easily be prevented by configuring the server to send the chain of certificates back to the root CA.

If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, there is no way for the browser to know that you even have HTTPS configured. Furthermore, you shouldn't deploy HTTP Strict Transport Security (HSTS) without 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

The problem of various sites configured for both protocols is recognized by The Tor Project and the Electronic Frontier Foundation and addressed by a multibrowser HTTPS Everywhere extension:

Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site.

Mixed content was also a huge problem due to possible XSS attacks to HTTPS sites through modifying JavaScript or CSS loaded via non-secure HTTP connection. Therefore nowadays all mainstream browsers warn users about pages with mixed content and refuses to automatically load it. This makes it hard to maintain a site without the 301 redirects on HTTP: you must ensure that every HTTP page only loads HTTP contect (CSS, JS, images etc.) and every HTTPS page only loads HTTPS content. That's extremely hard to achieve with the same content on both.

  • If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports it but in this case client (even HTTPS-compatible) will never know of HTTPS version is they load HTTP initially.
    – Cthulhu
    Commented Apr 2, 2017 at 7:30
  • Re your last paragraph: HSTS header is ignored during non-HTTPS connection.
    – Cthulhu
    Commented Apr 2, 2017 at 7:31
  • 1
    HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt
    – Cthulhu
    Commented Apr 2, 2017 at 7:42
  • Thanks for pointing out my false hint, Cthulhu! Inspired of that, I've made major improvements to my answer. Please be welcome to also be critical towards the new content. :) Commented Apr 2, 2017 at 8:46

In this day and age, TLS + HSTS are markers that your site is managed by professionals who can be trusted to know what they're doing. That is an emerging minimum-standard for trustability, as evidenced by Google stating they'll provide positive ranking for sites that do so.

On the other end is maximum compatibility. There are still older clients out there, especially in parts of the world that aren't the United States, Europe, or China. Plain HTTP will always work (though, not always work well; that's another story).

TLS + HSTS: Optimize for search-engine ranking
Plain HTTP: Optimize for compatibility

Depends on what matters more for you.

  • 16
    Maybe it's me being picky, but that first sentence seems a bit of a stretch: a site being https doesn't tell anything about the professionalism or the trustworthiness of the people in charge. A site can be https and still be developed/managed by people who don't sanitize inputs, making the site vulnerable to SQL injection or XSS; or it can be https and be invalid, not accessible, or not usable. Commented Apr 2, 2017 at 5:14
  • 34
    Using HTTPS isn't a guarantee of professionalism, but the lack of it most certainly tells the opposite. Commented Apr 2, 2017 at 8:56
  • 8
    The use of TLS and HSTS are signals, part of a much larger array, that the site may be worth reading. Unlike others, its trivially easy to test for the presence of, so that's why Google is using it as a proxy for the rest.
    – sysadmin1138
    Commented Apr 2, 2017 at 13:32
  • 3
    @Braiam Stack Exchange is migrating to https only and will start using hsts fairly soon. Http is still available, not because of compatibility, but because they are being slow and careful, and it is technically difficult to migrate.
    – captncraig
    Commented Apr 2, 2017 at 16:44
  • 4
    @esajohnson - lack of https doesn't showcase unprofessionalism. It shows there is no "need" for it. For example, a CentOS mirror.
    – warren
    Commented Apr 3, 2017 at 18:07

There is one good reason for simple read only websites not to use HTTPS.

  • Web caches can't cache images that are transported over HTTPS.
  • Some parts of the world have very low-speed international connections, so depend on the caches.
  • Hosting images from another domain takes skills that you can’t expect the operators for small read only websites to have.
  • 1
    Read-only contents can be deployed on CDN if you target those countries. The CDN mirrors the static contents using their own means and still serves them through HTTPS. CDN can be fairly easy to find and for small websites not that expensive to use. Commented Apr 2, 2017 at 18:25
  • 8
    @MaxthonChan, try explaining to my mother what a CDN is..... Yet she may setup a website with the times of local church services. Commented Apr 2, 2017 at 19:28
  • 6
    @MichaelHampton how can a cache read the image from a HTTPS stream without having the description keys? And would you trust an ISP with your keys? Commented Apr 2, 2017 at 21:51
  • 9
    You should make it more clear as to which caches you are talking about. Commented Apr 2, 2017 at 21:52
  • 2
    @IanRingrose If your mother is setting up a website with local church service info, it's unlikely that caching behavior on international connections will come into play, unless it's a very popular church.
    – Jason C
    Commented Apr 5, 2017 at 3:06

The maintainer claims that TLS must be optional. Why?

To truly know the answer to this question, you must ask them. We can, however, make some guesses.

In corporate environments, it's common for IT to install a firewall that inspects traffic incoming and outgoing for malware, suspicious CnC-like activity, content deemed inappropriate for work (e.g. pornography), etc. This becomes much harder when the traffic is encrypted. There are essentially three possible responses:

  1. Give up on monitoring this traffic.
  2. Install a root CA on users' machines so you can perform MitM decryption and inspection.
  3. Wholesale block encrypted traffic.

For a concerned sysadmin, none of these options are particularly appealing. There are a great many threats that attack a corporate network, and it is their job to protect the company against them. However, blocking a great many sites entirely raises the ire of users, and installing a root CA can feel a bit scummy, as it introduces privacy and security considerations for users. I remember seeing (sorry, can't find the thread) a sysadmin petition reddit when they were first turning on HSTS because he was in exactly this situation, and didn't want to block all of reddit simply because he was compelled by the business to block the porn-focused subreddits.

The wheels of technology keep churning ahead, and you'll find many who argue that this sort of protection is old-fashioned and should be phased out. But there are still many who practice it, and perhaps it is them with whom your mysterious maintainer is concerned.

  • how about terminating ssl at the frontend server/load balancer/similar and logging the traffic after that?
    – eis
    Commented Apr 2, 2017 at 15:22
  • 1
    @eis That assumes that the company controls every website that employees might visit, which is unlikely. The post does not appear to be about TLS on an intranet website. Commented Apr 2, 2017 at 16:35

It all comes down to your security requirements, user choice, and risk of implicit downgrading. Disabling old ciphers server-side is largely necessary because browsers will happily fall through to absolutely horrible ciphers client-side in the name of user experience/convenience. Making sure nothing of yours that depends on a secure channel to the user cannot be reached with an insecure method is, of course, also very sound.

Not allowing me to to explicitly downgrade to insecure HTTP when I've deemed that your blog post about why you like Python more than Ruby (not saying you do, just a generic example) isn't something I mind the spooks or the public knowing I accessed is just getting in my way for no good reason, on the assumption that HTTPS will be trivial for me.

There are, today, embedded systems which don't have the ability to use TLS out of the box, or ones which are stuck on old implementations (I think it's awfully bad that this is so, but as a power user of [insert embedded device here], I sometimes can't change this).

Here's a fun experiment: try downloading a recent version of LibreSSL from the upstream OpenBSD site over HTTPS with a sufficiently old TLS/SSL implementation. You won't be able to. I tried the other day on a device with an older OpenSSL build from 2012 or so, because I wanted to upgrade this embedded system to more secure, new stuff from source - I don't have the luxury of a prebuilt package. The error messages when I tried weren't exactly intuitive, but I presume it was because my older OpenSSL didn't support the right stuff.

This is one example where the move the only-HTTPS can actually detriment people: if you don't have the luxury of recent pre-built packages and want to fix the problem yourself by building from source, you're locked out. Thankfully, in the LibreSSL case, you can fall back to explicitly requesting HTTP. Sure, this won't save you from an attacker already rewriting your traffic, capable of replacing source packages with compromised versions and rewriting all checksums in HTTP bodies describing the packages available for download on the webpages you browse, but it's still useful in the much more common case.

Most of us aren't one unsecured download away from being owned by an APT (Advanced Persistent Thread: security jargon for national intelligence agencies and other extremely well-resourced cyber threats). Sometimes I just want to wget some plain text documentation or a small program whose source I can quickly audit (my own tiny utilities/scripts on GitHub, for example) onto a box that doesn't support the most recent cipher suites.

Personally, I'd ask this: is your content such that a person could legitimately decide "I'm okay with me accessing being public knowledge"? Is there a plausible chance of real risk to non-technical people accidentally downgrading to HTTP for your content? Weight your security requirements, enforced-privacy-for-your-users requirements, and risk of implicit downgrades against the ability of users who understand the risks making an informed choice on a case-by-case basis to go unsecured. It's entirely legitimate to say that for your site, there's no good reason to not enforce HTTPS - but I think it's fair to say that there are still good use-cases for plain HTTP out there.

  • 1
    "try downloading a recent version of LibreSSL from the upstream OpenBSD site over HTTPS with a sufficiently old TLS/SSL implementation" The flip side of this of course is: try downloading a recent browser with a sufficiently old browser, for example one that only implements HTTP/1.0 without support for the Host: header. Or try surfing modern sites with a web browser that only supports the Javascript of 2001. At some point we as a community need to move on, which unfortunately breaks things for some. The question then becomes: is the added value worth the breakage?
    – user
    Commented Apr 4, 2017 at 14:05
  • @MichaelKjörling Those are also problems, of varying severity. I'll add building recent compiler versions to that list. Some are more defensible than others. I'm not sure if you're asserting disagreement or why if you are: in the second sentence of my post, I agree that it is justified to prevent old ciphers on an HTTPS connection, since it protects most users from downgrade attacks they'd otherwise have no meaningful visibility into or defense against. (I don't think most modern websites failing to gracefully degrade is remotely as justified, but that's kinda beside the point.)
    – mtraceur
    Commented Apr 7, 2017 at 7:33
  • @MichaelKjörling To clarify, the point of bringing that up was because it's an example of where providing plain HTTP to the user had a clear benefit, which was the core point of the question being answered. It was not in any way to cast a negative light onto the OpenBSD/LibreSSL projects, for which I have pretty substantial respect. I thought the second sentence of the first paragraph would've ruled out such a negative interpretation. If you think that was unclear or could be worded better, please feel free to edit my answer or suggest improvements.
    – mtraceur
    Commented Apr 7, 2017 at 7:38

There is a lot of discussion here as to why tls is good - but that was never asked as in the original post.

Maxthon asked 2 questions:

1) why has has a random, un-named site decided to maintain both http and https presences

2) Is there a negative impact to Maxthon serving only 301 responses to http requests

With regard to the first question, we don't know why the providers chose to retain both http and https sites. There may be lots of reasons. In addition to the points about compatibility, distributed caching, and some hints about geo-political accessibility, there is also a consideration about content integration and avoiding ugly browser messages about the content being insecure. As Alvaro pointed out, TLS is just the tip of the iceberg with regard to security.

The second question, however is answerable. Exposing any part of your site of your website via http when it actually requires https for secure operation provides an exploitable vector for attacks. However it does make some sense to maintain this in order to identify where traffic is being incorrectly directed to port 80 on your site and fixing the cause. I.e. there is both a negative impact and the opportunity for a positive impact, the net result depends on whether you are doing your job as an administrator.

Sysadmin1138 says that https impacts seo rankings. While Google have stated that it does impact rankings, the only reliable studies I have seen suggest the difference is small. This is not helped by people who should know better claiming that, since top ranked sites are more likely to have an https presence, an https presence therefore improves rankings.


In the past, I've had to use HTTP rather than HTTPS because I've wanted to <embed> pages from elsewhere that themselves have been served over HTTP, and they won't work otherwise.

  • You can use your server to reverse proxy an SSL'd version. Commented Jul 25, 2018 at 17:18

This is not a good reason, as it means you have bad/broken/insecure clients, but if there are automated processes accessing resources via the existing http:// urls, it's possible that some of them do not even support https (e.g. busybox wget, which doesn't have TLS support internally and only added it more recently via an openssl child process) and would break if they were given a redirect to an https url that they can't follow.

I would be tempted to deal with this possibility by writing the redirect rule to exclude unknown (or known-legacy) User-Agent strings from being redirected and let them access the content via http if they want, so that actual browsers can all benefit from forced https/hsts.

  • 1
    Remind me how many decades ago any well maintained tool (e.g. wget) didn't support HTTPS? Commented Apr 4, 2017 at 10:18
  • @OlegV.Volkov: I think you missed the word busybox in my answer. Commented Apr 4, 2017 at 14:35
  • Checked it out - well, now I see. I don't really get why then can't just build the damn thing and then don't package build tools but whatever. Thinking back I also remembered some more cases when people was restricted to stripped down or outdated tools and it would be good to have plain HTTP. Could you please fix caps so I can revert vote after edit as well? Commented Apr 7, 2017 at 12:32

There are very few good reasons for using HTTP instead of HTTPS on a website. If your website handles transactions of any kind or stores any kind of sensitive or personal data, you must absolutely use HTTPS if you want said data to be secure. The only decent reason I would see for not enforcing HTTPS is if your website relies on caching as HTTPS does not work with caching. However, it is often worth sacrificing a bit of performance in order to ensure security of your website. It is also possible that your clients may not support HTTPS, but really, in 2017, they should.

You must log in to answer this question.

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