50

I know the many benefits of SSL for the users of a website. It creates a contract whereby the user can be certain that the entity they're transacting with is who it claims to be and that the information passed is encrypted. I also have some idea about other benefits (e.g. speed benefits from HTTP/2).

But something I was wondering recently was whether the website benefits in a similar way from this transaction. That is, does my website become more secure from attacks if I enable SSL? I suppose because I would also know that the client I'm transacting with is certified and information I send them is encrypted. But can't any client act unethically and access my website with self-signed certs, etc., claiming to be whoever they like?

By the way, I've come into what knowledge I have in a self-directed way, so if this is a basic question or an XY problem don't hesitate to point me to elementary resources or set me straight.

Edit: For everyone continuing to answer or comment with general reasons to use SSL: these are appreciated and no doubt of use to new users. That said, I do make it a part of each website I set up, and was curious specifically about the security benefits. In SE tradition I just want to remind people to keep to the question if possible. (Sorry about the title originally missing the key qualifier!)

Luke Sawczak
  • 650
  • 5
  • 9
  • 12
    +1 for self-flagging as an XY problem. (it's not though, good question) – Mike Ounsworth Sep 13 '17 at 15:41
  • 14
    In most cases, SSL doesn't prove anything at all about the client - certainly, most websites don't need clients to have any form of certificate (although there are ways to require it). At the basic level, it allows for the traffic in both directions between a client and a server to be encrypted, and in some cases, for the client to verify that the site belongs to a specific owner. – Matthew Sep 13 '17 at 15:42
  • 18
    The main incentive now is that when a user tries to type something in your site they won't get a "THIS SITE IS INSECURE DON'T ENTER SECRET INFORMATION" message. – user253751 Sep 14 '17 at 02:45
  • 9
    "The user can be certain that the entity they're transacting with is who it claims to be" is possibly misleading. The user can be certain that the website owner owns the website and the server certificate, but not that the website is owned by anyone in particular. A phishing site with a plausible domain name can still use HTTPS urls but not be associated at all with the "real" domain. Only EV allows that higher level of trust. – Andrew Leach Sep 14 '17 at 09:48
  • 5
    Related reading/FAQ: https://doesmysiteneedhttps.com/ and https://whytls.com/ – StackzOfZtuff Sep 14 '17 at 11:33
  • 1
    There is a killer argument: your users are logging in and somebody may steal their credentials and abuse your site. Think of webmail. Your user is upset because someone reads their mails, but you're having a problem, because somebody uses your server to send spam via your server and gets you blacklisted. – allo Sep 14 '17 at 12:43

11 Answers11

63

It prevents the ISP from injecting their own ads in place of your own. If you rely on advertising for revenue, https helps protect your revenue stream.

59

You have a few good questions, and a few misconceptions. Let's try to untangle them.


I also have some idea about other benefits (e.g. speed benefits from HTTP/2).

Another important one: Search Engine Optimization since you get GooglePoints for having TLS. (which kinda feeds your point that webmasters need external incentives ...)


I suppose because I would also know that the client I'm transacting with is certified and information I send them is encrypted. ... But can't any client [sic] access my website with self-signed certs?

Yes and no, and yes, ... and no. Let's untangle this.

TLS client authentication (requiring clients to present certs) is something you usually see on VPN servers, enterprise WPA2 WiFi access points, and corporate intranets. These are all closed systems where the sysadmin has full control over issueing certs to users, and they use this to control which users have access to which resources. This makes no sense in a public website setting, and is definitely a non-standard config for an HTTPS webserver.

That said, what you do gain is this:

Encrypted TLS session
| Client loads login page
| Client sends username / password
| Client does "logged in things"

So you do gain extra confidence that the user is who they say they are because the username / password is no longer sent in the clear, therefore no longer possible for a man-in-the-middle to intercept / modify / steal.

After that any of the data the client sends to the server, or gets from the server, is end-to-end encrypted to the client. Generally you're right: this protects the client more than the server, but it does stop man-in-the-middles from injecting malicious stuff into files that the user uploads, injecting malicious commands to be executed as if they came from that user.


But can't any client act unethically and access my website with self-signed certs, etc., claiming to be whoever they like?

Kinda, yes. For a public website, anybody can open a TLS connection. If you want users to authenticate, you need to have a login mechanism on top, TLS has does not generally provide this for you (unless you're using the above-mentioned client cert mechanism).


But something I was wondering recently was whether the website benefits in a similar way from this transaction.

Basically, the benefits to the server are that any data sent to the user will only be viewed by the intended user. If, for example, you are sending them copies of their financial statements, then your lawyers will be very happy to hear this. It also means that any data received from the user did in fact come from that user, and not from an attacker pretending to be them.

If your legitimate users are acting maliciously, well that's a different problem, after all, you chose to give them access to the system. What TLS (+ your own login framework) does is ensure that only legitimate users have access. What they do with that access is not TLS's problem.

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • Thanks, this was very helpful. Not only did you clear up my misconceptions, you also addressed my main question about whether there are *security* benefits for the server. – Luke Sawczak Sep 14 '17 at 00:45
  • On reading your edit, I think the OP has 2 major confusions: 1. there is always a client-cert involved and 2. that you can't control trust for client-certs. – JimmyJames Sep 14 '17 at 17:25
  • @JimmyJames Indeed, and I've now been given to understand the rare use cases and relative security of systems that *do* use client certification. – Luke Sawczak Sep 15 '17 at 01:08
  • 4
    As the last paragraph points out, you can't use technology (HTTPS) to solve a people-problem (unscrupulous users). You can only use technology to solve technology/process problems (the ability to eavesdrop/modify the conversation). After that, you're on your own. – Clockwork-Muse Sep 15 '17 at 20:28
  • In other words there's a huge amount of reputational benefit. – Ben Sep 17 '17 at 19:32
  • 1
    "any data received from the user did in fact come from that user, and not from an attacker pretending to be them" -- well, subject to a careful definition of "user" meaning, "the other end of this TLS session". Whether that's legally equivalent to "the human being that we're going to act as if the instructions came from", is a matter for your jurisdiction's courts to decide ;-) – Steve Jessop Sep 18 '17 at 11:06
21

One of the largest benefits for a site operator is increased trust from users; we often hope that they check for the presence of HTTPS before entering credit card details into an ecommerce site, for instance, and the "green lock" of an EV certificate provides some additional verification that the website is operated by the entity they claim to be.

How large of an effect this has, I don't know. The Stanford Web Credibility project has a collection of recommendations for making a website appear credible, and HTTPS doesn't appear on the list. However, the papers cited there are all 15-20 years old at this point. Much has changed in technology then, but the real question is how much people have changed.

Xiong Chiamiov
  • 9,402
  • 2
  • 35
  • 78
8

HTTPS only protects the transport against sniffing or modifying, i.e. against an attacker in-between client and server but not against an attacker at the server or client itself. It does neither make the server itself magically more secure nor does it make the client more trustable to the server. This means a HTTPS protected server can for example serve malware and a client connecting with HTTPS can still exploit security problems at the server side like SQL injection or similar.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
5

Many browsers (Firefox does this very prominently) warn users against entering their passwords on non-secure websites. Website owners naturally do not want their users to see this big scary warnings (which, in the case of Firefox, also make automatically filled-in login details tricky to use), and securing their sites is the only way to get rid of them.

So if the website allows for users to log in, there is a strong incentive to add security. This is an external incentive, forced by browser vendors.

TRiG
  • 610
  • 5
  • 14
3

A standard SSL setup does not provide any security benefit to the server, per se. They do know that the they traffic two and from the endpoint which made the encrypted request has not been manipulated in transit, but there are no guarantees that the endpoint which made the request is not serving as a MITM.

It is possible to configure SSL in such a way where you can validate the clients. Most webservers (Apache, nginx, IIS, etc.) will allow you to set up client certificate-based authentications, meaning each client which is accessing the website will have their own unique certificate, and the webserver will not serve pages to any client which does not have a valid certificate. Distributing and maintaining the client certificates is a large amount of overhead, so this type of setup is usually only done in environments with a limited number of clients, such as intranet apps, APIs with a small number of users, etc.

Qsigma
  • 107
  • 3
Dan Landberg
  • 3,312
  • 12
  • 17
2

Good answers so far I just want to add following:

Not every TLS (older SLL) has same security level so It's good to check it against https://www.ssllabs.com/ssltest/ .

And TLSv3 has some vulnerabilities so request to disable in server config.

I'm not going to say TLS is bullet proof versus MitM as we know ssl stripping and HSTS bypass is possible but it makes much harder for an attacker to do it as he needs to be in the same network as the user.

The most benefit beside secure communication is that you get better Google SEO ranking as websites with TLS get easier to the top as referenced here http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446 .

Then as a company the end user when he sees the lock in web browser has some more secure feeling, I know it's a bit stupid as I set many static websites with TLS/HTTPS where no data was going from server or to server but for sake of SEO and end user experience.

Xiong Chiamiov
  • 9,402
  • 2
  • 35
  • 78
  • "... every TLS (older SLL)...", don't you mean "...(older SSL)..."? – Miguel Sep 13 '17 at 20:16
  • 3
    There is no TLSv3. Your probably mean SSL 3.0 (SSLv3) which then got followed by TLS 1.0 (TLSv1) etc. – Steffen Ullrich Sep 13 '17 at 20:57
  • Yep Steffen sorry I use Nginx so from config i got used to it to say TLS. Miguel I mean old SSL as TLS is new name for SSL after SSLv3.1 more info here: https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https – Hrvoje Milković Sep 14 '17 at 06:54
2

To play devil's advocate here, enabling TLS in your webserver if you do not need it (ie. no sensitive information is passed between server and client) might actually reduce security.

For the simple reason: it adds way much more code, and more code means more bugs and bigger attack surface. So you might get issues like Heartbleed, remote code execution and other problems which you wouldn't have otherwise.

Of course, the problem is moot - there is pretty sure way more bugs in whatever code runs your dynamic web than in your web server TLS library, so unless you're running very small audited HTTP server with static content only, the reduction in security is probably negligible.

And HTTPS (apart from being good SEO for google and friends) might protect you from some evils like MitM attacks (then again, due to failures with HTTPS CA model, it is mostly "feel good" "security" as you're forced to "trust" dozens of CAs you have absolutely no reason to trust whatsoever)

Matija Nalis
  • 2,265
  • 13
  • 19
  • 1
    Of course, if you want to avoid this, then you'd need to make sure that the web server hosts **no** SSL/TLS protected content. It's not about your site or not your site; it's about whether the code is there and running at all or not. – user Sep 15 '17 at 12:56
  • Please be more clear in your answer that in all practical cases using TLS is an improvement to *all parties involved*. I know it's attractive to be contrarian to look in these kinds of sections, but people come to this website to get security advice and also for rationale *not to do something*. Discussing edge cases like this therefore might not helpful. It's very likely there will be people that only read your first two paragraphs and leave it be. – DCKing Sep 18 '17 at 09:29
  • @DCKing I specifically emphasized in 1st paragraph that this is applicable only if "you do not need it (encyption)" in case you do not handle any sensitive information. The last two paragraphs are just additional explanation that even if you **do handle sensitive information**, HTTPS as it is implemented today is sadly lacking for providing transport security. – Matija Nalis Sep 18 '17 at 22:51
1

The benefit to the website owner? Their users are safer. There's no real benefit to website owners other than that, and that's why a lot of websites still don't have HTTPS/SSL (because setting up HTTP/SSL actually takes work that the website owner doesn't see any direct benefit from).

Keeping users safe should be the most important priority to website owners, but unfortunately it often isn't.

micheal65536
  • 1,746
  • 1
  • 10
  • 14
1

SSL ensures people cannot (easily) pretend to be you. That's a plus. In addition, if you're dealing with Personally Identifiable Information (PII), SSL provides additional security, which helps prevent the embarassment of somebody stealing your customer's information. In many countries, you are legally required to take steps to protect your customers' PII, and SSL is one of the ways you can do that.

If you want your website to be found through Google, SSL has the additional benefit that it puts you higher in the search results, albeit only slightly.

Tijmen
  • 146
  • 3
  • I like this angle - that your "security" in a different sense depends on the security of your users... – Luke Sawczak Sep 14 '17 at 11:12
  • It absolutely is. If your business gets a reputation of 'not caring about customers privacy', that's going to be bad for business. If your customers' credit card info gets stolen from your servers, or intercepted through a MitM-attack, you could even be brought to civil court. Protecting your customers is a must for companies today. Also, SSL is very cheap (or even [free](https://www.openssl.org/)) these days, so there's really no reason not to offer it. (I'm not affiliated with OpenSSL btw.) – Tijmen Sep 14 '17 at 11:17
1

As others have pointed out, SSL (or TLS) increases trust with your users.

Unbounce cited this in a recent blog article:

As GlobalSign, a web-trust certificate provider discovered, 84% of website visitors surveyed said they would abandon a purchase if they knew the data was going to be sent over an insecure connection.

In fact, this now impacts business owners more directly: Google Chrome has started marking non-SSL sites as 'not secure'.

SSL/TLS reduces liability to the site owner. Traffic is not easily spoofed or intercepted. Your more litigious customers won't have cause to sue you for negligience.

You get an SEO boost in major search engines, including Google. See https://moz.com/blog/seo-tips-https-ssl

It doesn't cost much. With providers like letsencrypt and AWS certificate manager, SSL/TLS certs free are easier than ever to setup

Dan Esparza
  • 113
  • 5