What is the benefit of forcing a site to load over SSL (HTTPS)?

Question

Let's say I have a large content-only site; no login or logout, no usernames, no email addresses, no secure area, nothing secret on the site, nada. People just come to the site and go from page to page and look at content.

Besides a slight bump in SEO from Google (very slight, from what I've read), is there any benefit of forcing the site to load via HTTPS?

Solution 1

HTTPS does not just provide secrecy (of which you are doubting the value, though there are good reasons for it still) but also authenticity, which is always of value. Without it, a malicious access point/router/ISP/etc. can rewrite any part of your site before displaying it to the user. This could include:

• injecting ads for your competitors
• injecting ads or annoying widgets that make your site look bad and harm your reputation
• injecting exploits to perform drive-by downloads of malware onto the visitor's computer, who then (rightly!) blames you for it happening
• replacing software downloads from your site with ones that have bundled malware
• lowering the quality of your images
• removing parts of your site they don't want you to see, e.g. things that compete with their own services or depict them in a bad light
• etc.

Failure to protect your users from these things is irresponsible.

Solution 2

"nothing secret on the site"

...According to you. There migh be a perfectly fine reason someone wants a secure connection. It (partly) creates privacy:

My admin can see that I'm browsing some picture site on my phone via url, but he can't tell if I'm watching pics of cute cats or hardcore porn. I'd say that's pretty damn good privacy. "a content" and "the content" can make all the difference in the world. – Agent_L

You might think it's insignificant, or maybe it's not a big deal now but could be at another point in time. I am a firm believer that no-one apart from me and the website should know exactly what I'm doing.

It creates trust. Having the padlock is a sign of security and it can signify some degree of skill regarding the website, and thus your products.

It makes you less of a target for e.g. MitM attacks. Security increases.

With initiatives like Let's Encrypt, which make it a lot easier and free, there aren't many downsides. CPU power taken up by SSL is negligible these days.

Solution 3

You get HTTP/2 support, the new web standard designed to significantly improve website loading speeds.

Because browser makers have chosen to support HTTP/2 only over HTTPS, enabling HTTPS (on a server that supports HTTP/2) is the only way to get this speed upgrade.

Solution 4

(Parts taken from my answer to a similar question.)

---

HTTPS can achieve two things:

• Authentication. Making sure that the visitor is communicating with the real domain owner.
• Encryption. Making sure that only this domain owner and the visitor can read their communication.

Probably everyone agrees that HTTPS should be mandatory when transmitting secrets (like passwords, banking data etc.), but even if your site does not process such secrets, there are several other cases where and why the use of HTTPS can be beneficial.

Attackers can’t tamper with requested content.

When using HTTP, eavesdroppers could manipulate the content your visitors see on your website. For example:

• Including malware in the software you offer for download (or if you don’t offer any software downloads, the attackers start doing so).
• Censoring some of your content. Changing your expressions of opinion.
• Injecting advertisements.
• Replacing the data of your donations account with their own.

HTTPS can prevent this.

Attackers can’t read requested content.

When using HTTP, eavesdroppers can learn which pages/content on your host your visitors access. Although the content itself may be public, the knowledge that a specific person consumes it can be problematic:

• It opens an attack vector for social engineering.
• It infringes privacy.
• It can lead to surveillance and punishment (right up to imprisonment, torture, death).

This, of course, depends on the nature of your content, but what seems to be harmless content to you can be interpreted differently by other parties.

Better be safe than sorry. HTTPS can prevent this.

Solution 5

It prevents man in the middle attacks that make you think you are visiting your site but present a page that is actually from another and may attempt to get info from you. Since the data is encrypted, it also makes it more difficult for an attacker to manipulate the page as you see it.

Because you need a SSL certificate, that verifies you are the owner of the site at a minimum giving at least some verification of who you are.

View more solutions

Comments

[unor]

Possible duplicate of Force Using SSL on Site now?

[Stephen Ostermiller]

I don't believe this is a duplicate of Force Using SSL on Site now?. Although some answers may end up being similar, that question is asking for advice about whether or not to use SSL while this question is not. If anything, the other question should be closed for being opinion based.

[Mike -- No longer here]

I call this an opinion-based question because SSL is generally used for secure sites, and you're trying to find a reason for loading an insecure site over SSL vs non SSL and the answers will likely be resulted from people's opinions of SSL

[VLAZ]

Let's flip this around: what is the benefit of NOT using SSL? There isn't any that I know of. Oh sure, the implementation which would be a one off and take (comparatively to everything else) no time. So, if one approach has no downsides and some upsides, the other has no upsides and (according to you) no downsides, then...why stick with the latter?

[Jules]

@Vld - performance. These days, we often try to optimize site initial load times to sub-second performance figures, with a goal of 1/2 second. On a slightly slow internet connection (packet latency around 100ms) the SSL handshake can easily take 300ms, which might well push you over a performance goal. For mobile users its worse: mobile networks have longer packet latencies and processing time for the certification verification could easily be another few hundred ms on a slower phone.

[André Borie]

Mobile carriers always tamper with unencrypted HTTP traffic, whether it's for image (over)compression, injecting evil Javascript or more agressive cache-control headers. HTTPS will prevent all that nonsense.

[Hack-R]

Slightly fewer people will be able to see traffic to and from the site. I'll still be able to see it and Big Brother will and Big Business will if it wants to, but a few amateur hackers my stumble over Ye Olde Encryption.

[user253751]

@Vld Why do you say that having to set it up isn't a downside?

[VLAZ]

I'm saying it takes negligible amount of time compared with everything else. In fact, I can tell you for a fact that if OP was concerned about time, then this question has already taken more time to resolve than setting up SSL would have. If OP has the time to spare on asking this question, he should have the time to spare to set up SSL. That's if there is even setup needed by him. If somebody else is hosting the content, they can take care of it. Heck, that doesn't even involve major changes to an application, if that's what you're getting at, since you can just have a reverse proxy.

[Agent_L]

@Vld We assume that OP is concerned about time, because everybody should be concerned about time. Not being concerned about time makes you lose customers. And you're wrong, on mobile SSL can easily be the largest time hog. You clearly sit on a fast computer and fast connection, but we're concerned about end user experience, not admin experience.

[mihanik]

HTTP/2 only works over TLS! So if performace is an issue, with recent browsers TLS connections are faster! Try it yourself at one or another of the many test sites or read a blog about it. Without TLS, you can only provide legacy HTTP/1 to your users.

[Agent_L]

@Josef Not true. HTTP/2 works over unencrypted connections just as well. No browser can do that, but that's browser limitation, not HTTP/2. Saying that "HTTP/2 only works over TLS" is like saying that "technology X doesn't work because Internet Explorer don't implement it". Look where it took us.

[mihanik]

nothing can do HTTP/2 unencrypted. Saying HTTP/2 works without TLS is like saying your car can drive 500MPH. Sure, if someone puts a rocket on it it might work, but right now it doesn't and it is highly likely it never will.

[Matthew Whited]

SSL/TLS also breaks proxy servers. Yes they still exist and yes they are still useful.

[user]

@MatthewWhited Citation, or at least an example, please? Passing traffic through a local proxy that runs your traffic through Tor most definitely doesn't break HTTPS, for example, and I can't see any legitimate reason why HTTPS would break proxies. (I can see reasons why proxies might break HTTPS, but that's not what you said.)

[Matthew Whited]

I didn't say proxy breaks HTTPS. I said HTTPS breaks proxy servers. They are not able to cache or analyze traffic if it is encrypted. Yes the data can be tunneled but that only adds overhead without cache benefits.

[Schwern]

Unfortunately SSL does not stop corporate IT or your ISP or people on the public cafe wifi with you from knowing what sites you're visiting. The DNS lookups are still done in the clear. While they can't see the content, nor the exact URL, nor that you're even using a web browser, they can see that you're accessing penisland.com (which is, of course, a site for pen enthusiasts, but might be misconstrued). Using a VPN or SOCKS5 proxy will protect your DNS queries.

[Martijn]

Yes, but saying "dont use https because there is DNS lookups" is like saying "YEah I have no lick because they can break a glass". Https should be standard IMO, just as the lock. It's a fine first step :)

[Kevin]

@Martijn: With Server Name Indication (which all modern browsers support), the hostname of the website is itself sent in the clear as part of the HTTPS handshake. It's not just a matter of sidechannel attacks and cannot be mitigated with e.g. DNSsec.

[user]

Indeed, HTTPS can prevent it. In some situations, it might not. See Lenovo Superfish for a fairly recent example.

[unor]

@MichaelKjörling: Yes, I’m aware of this (that’s why I made sure to use "can" ;)), but it’s an issue stemming from the behaviour of the visitor, not an issue with HTTPS itself or the way the webmaster uses it, right? The visitor should care about which CAs to trust (and the visitor should care about which software to install, especially if it has the permission to fiddle with the list of CAs to trust).

[user]

Indeed; I'm not arguing against your point, only adding to it!

[user]

It's not a perfect citation for the claim made in the answer, but there's always Marking HTTP As Non-Secure.

[Mike -- No longer here]

But if the data is compressed, then such injection you describe may be difficult to produce.

[ceejayoz]

@Mike Not really. There's plenty of off-the-shelf software to do this, and it all handles decompression and recompression just fine.

[Schwern]

@Martijn Absolutely do use HTTPS, but it only creates privacy about the URL and page content. It doesn't prevent your IT department from knowing what sites you're visiting. You need more than HTTPS for that.

[Nayuki]

@Mike Not really. A full rewriting proxy can decode all the traffic and inject whatever new stuff it wants afresh.

[Gianpiero]

FYI most if not all of my examples have actually been seen in the wild.

[user]

@Schwern I never understood the argument that HTTPS doesn't protect the host name because the DNS lookup and SNI and the server's certificate are in the clear. Of course that's true as stated, but plain text HTTP is by no means any better in this regard!

[Martijn]

Ok, changed the example just a bit, though the simple example (though incorrect) could demo a situation the OP didnt think of :)

[user253751]

@MichaelKjörling What does whether HTTP exposes the server name have to do with whether HTTPS exposes the server name?

[Akash]

Just a small addition left, referer links won't be propagated to a another host. This can be considered as "security" feature. Just as an idea: If you have a content only side, which refers to another site, the target site could parse your referer link and adapt their content or even layout to the referer to act like your page and collect data or something like that.

[Antzi]

@Schwern alternative DNS such as DNSCrypt works too.

[Schwern]

@Antzi Looks interesting! Does that work for any host? Or just for hosts which support it?

[Schwern]

@MichaelKjörling Nobody here is arguing HTTP is better. As I said, the problem is giving people the idea that HTTPS means privacy (kudos to Martijn for editing the answer). This might lead someone to compromise themselves thinking their browsing is safe from scrutiny because they're using HTTPS. HTTPS is one element of ensuring privacy.

[Antzi]

@Schwern it runs a DNS server on your computer. Connections between the DNS server and the outside world runs on SSL, while your applications use the normal, non encrypted SSL connection to the (local) DNS server. This way the unencrypted traffic does not leave your computer.

[Agent_L]

@Schwern My admin can see that I'm browsing tumblr on my phone, but he can't tell if I'm watching pics of cute cats or hardcore porn. I'd say that's pretty damn good privacy. "a content" and "the content" can make all the difference in the world.

[Schwern]

@Agent_L No, even that is not good advice. If you go to https://penisland.tumblr.com/ your browser will do a DNS request for penisland.tumblr.com which, unless you've protected your DNS queries, the network admin can see. Then your browser has to get the images, Javascript, CSS, and ads from various domains which generate more DNS requests. They could be from any domain. The few porn Tumblr domains I tried don't have anything obvious, Tumblr tends to host images and videos in house, but you cannot rely on that for privacy.

[Gianpiero]

@DavidMulder: Indeed that final comment is mostly unrelated to image-quality-lowering, though it could matter to them if you're serving high-res photos/wallpaper/etc. and your users end up inadvertently getting junk. On your second point I fail to see how "contributing to the decentralization of the internet" is "definitely not a good thing". I think you either accidentally said the wrong thing or you have a very user-hostile agenda...

[David Mulder]

@R.. By using https you are contributing to the centralization of authority on the internet (you could of course use self signed certificates, but hardly anybody does that). I am not sure how that's a user hostile agenda, because centralization of power seems to be a long term danger to all users

[jiggunjer]

@DavidMulder your first comment said "decentralization [...] not a good thing"

[VLAZ]

It seems we are presented with a dilemma - let's call it a two-sided coin. If the coin falls one way, the Internet gets decentralised and this is not a good thing. If the coin lands on the reverse, the we go for centralisation and doom the Internet to an eternity of collapse. Either way, the game is rigged.

[Agent_L]

@Schwern You're right about the subdomains, I overlooked that. But it only means that a site can sacrifice privacy of the users for prettier urls. Tumblr was wrong example, my bad. But not every site does that.

[Gianpiero]

Can we please not turn the comments on this answer into an off-topic bikeshed-esque rant on unrelated issues?

[Dan Cieslak]

This is pretty huge and needs to be hyped more. It makes a business case for loading HTTPS only that most managers can get behind.

[David Mulder]

@jiggunjer You're absolutely right, I do not get how I could get that pointed out and not realize what you meant.

[David Mulder]

@R.. Are you implying that centralizing the internet is a minor thing compared to the benefits of SSL in situatiouns like the OP is talking about?

[Gianpiero]

@DavidMulder: No, I'm stating that it's unrelated to the topic of the question or this answer. If you want to discuss that open a new question about whether use of HTTPS "contributes to the centralization of the internet" on an appropriate SE site. Or if you think it's actually relevant to the question (again: I don't) then write your own answer explaining your reasoning.

[David Mulder]

@R.. When a question asks for the benefits of doing something with the clear implication that the OP is challenging those benefits, it seems prudent to mention disadvantages as well. Bikeshedding is talking about something unimportant, this answer is actively contributing and promoting the centralization of the internet. (Not that I was planning a discussion, but at the point you called it a bikeshed-eque rant and an unrelated issue that was too much)

[Schwern]

@Agent_L Go into Tools -> Web Developer -> Network in Firefox (other browsers have similar) and watch the requests it's quietly making. All those domains can be seen on the network. Enough info leaks out around SSL that someone sniffing the network can know if you're looking at a controversial site. Don't tell people SSL alone hides what sites they're visiting. Don't tell them it's ok because they might get lucky on a big site like Tumblr or Google or Facebook. It's false security. Tell them to use secure DNS, or better yet, a non-logging VPN.

[Gianpiero]

@DavidMulder: Again, take it elsewhere.

[Agent_L]

@Schwern I already admitted you're right. But I never said it hides sites, I said it hides content within one site. Your example with subdomains shown that one has to be extra-careful even with that.

[user]

This is a bit like saying that if Eve can see Alice's car's VIN number through the car's windshield, it makes it easier for Eve to break into Alice's car because the VIN number allows her to find out what brand and model car Alice owns. Sure, it's a possibility, but there are tons of ways to get much the same information without MITM'ing anything, in ways that would barely register as anything more than the Internet background noise for a leaf node on the network. For example: Eve (or perhaps Mallory) could e-mail Alice a link to a web page under their control. People love to click on links.

[Michael Yaeger]

IMO, this is just as much of a correct answer as the one getting all the votes.

[user]

youtube.com/watch?v=e6DUrH56g14 mentions some techniques to mitigate the performance impact even if you (or a large share of your clients) can't do HTTP/2 for some reason.