How risky is it not to install ssl?

Question

I would like to have more insight about when a server should install ssl, in particular when it is worth the money to pay for a valid certificate. As my clients often have little understanding of why they need ssl, and since a certificate is quite costly compared to renting a vps, I would like to know some statistical numbers or other descriptive information.

Suppose a user forum, which has thousands of users, and all their usernames and passwords are sent unencrypted over the internets. There are no credit card informations, or other sensitive data, except the passwords. What would be the arguments for acquiring ssl in this situation, and what would be the arguments not to?

I hope this question is intelligible. I wouldn't know really how to ask more directly.

Thanks for your time and advice!

Answer 1

Without SSL, all that is sent over the wires can potentially be spied upon or altered by indelicate routers. "Altered" includes hostile hijacking of connections and Man-in-the-Middle attacks. These are relatively easy to setup by attackers in the context of WiFi hotspots -- which means that if a user is accessing your Web site from a restaurant or a public park (using his laptop or tablet) then his data (in particular passwords and cookies) can be silently eavesdropped by ill-intentioned people equipped with a readily available 100$ gadget.

Moreover, not only are non-SSL connections easily commandeered by hostile outsiders, but people begin to know it. When your users see that you use passwords without SSL, some of them will think that "you do not care about their security". That alone is not a good thing. You want your users to feel safe, otherwise they'll be tempted not to be your users anymore.

---

SSL costs are routinely exaggerated, for reasons which are not completely clear (there is some theory on the subject):

• On the server: the extra CPU and network overhead implied by SSL is in the 2% range, i.e. not a lot. Biggest indirect cost is that SSL prevents some transparent proxies (run by some ISP) from doing their optimization; it might have some impact if your server hosts big static files. The cost of the certificate can be zero -- or, more accurately, no buying fee, and some administrative task once a year. Even in commercial contexts, the cost of the certificate is negligible with regards to the hosting costs and sysadmin time.

• On the client: the main effect is increased latency for the very first connection. When opening the first connection, client and server run the full TLS handshake. But the connection will be kept open for subsequent HTTP requests (the normal "keep alive" mechanism), and if the connection is closed due to prolonged inactivity, new connections will use the abbreviated handshake which reuses the cryptographic elements from the previous connection. the abbreviated handshake is much faster, especially since it implies one less network round-trip.

Nothing beats actual measure, so you are encouraged to experiment, if only with a homemade certificate (aka "self-signed"); but, on the whole, SSL cannot be considered as really expensive (it used to be expensive, 15 years ago, but computers have grown a bit in computational power since these times).

Answer 2

Without SSL, it will be trivial to takeover user accounts through a MITM attack. All the usernames and passwords are sent over in cleartext, making it really easy to sniff. This has a rather severe indirect consequences if users reuse the same username/password combination across multiple sites.

There are plenty of other attacks if SSL is not activated, but I feel this is simple and severe enough to illustrate the point.

A more indirect effect of SSL (or a valid SSL certificate rather), is that the padlock on the browser inspires confidence in users. It is rather difficult to explain to non-technical users the reasons for SSL. It is slightly easier to train them to associate the green padlock with a secure site. Not have the same padlock might lead to users questioning(rightly), the security of your site.

If cost is an issue, there are quite a few free SSL cert providers, such as StartSSL. Do note that I have never tried their services before so I am unable to vouch for their reliability.

Answer 3

Without SSL, users' data is transmitted over the wire unencrypted. Is that an acceptable risk?

Everyone here is using a discussion forum that does not use SSL (and SE is not unique in this regard; e.g., reddit doesn't use SSL)¹.2017 EDIT: stackexchange and reddit now both use SSL unlike when this answer was written in 2013

A network eavesdropper between my computer and stackexchange's servers (e.g., other users of the same wifi access point, or at my ISP, or network administrators at my work) could steal my authentication cookies or alter my messages and get full access to my stackexchange account. I'd rather that not happen, so I don't use stackexchange on public wifi and trust my ISP to not steal and misuse users' secret information.

Granted, this is a risk I'm willing to take. While someone capturing my stackexchange account (temporarily until my session cookies expire), they wouldn't capture much information and most of their actions could be later undone (e.g., any edits can be reverted).

Also, don't equate SSL on VPS with full privacy. You still must inherently trust your VPS host, which can easily grab your private SSL certificate from your VM (its on a file on their disk) and then decrypt all your incoming traffic. I doubt most reputable VPS providers would do that, but they definitely could.

---

¹Well stackexchange let's you authenticate through an OpenID provider like google/facebook/yahoo/etc, and those providers will use an https connection (at least everyone I checked) so the password is sent encrypted. They do have a "login with stackexchange" option which directs you to a http page that uses javascript, so the form submission with the password should be transmitted encrypted (using SSL). Granted, it would be trivial to launch a MitM attack on this, as the https connection is not readily apparent to the user. And again, while the attacker cannot grab your password, they can later grab the session cookie so they will appear as an authenticated version of you.

Similarly for reddit.com, they (secretly) use SSL for the form action, but as the form is hosted on a non-ssl page it is easy for an attacker to launch a MitM attack and capture your password. Granted reddit.com does have an SSL version with a properly signed CA, but this site is not on their CDN and is only meant to be used by advertisers/people making credit card transactions at the moment.

Answer 4

is quite costly compared to renting a vps

This surprised me - a quick check on the internet and a basic certificate (single site, no EV, but recongised chain) can be had for less then a tenth of the price of low end VPS hosting.

What would be the arguments for acquiring ssl in this situation

You have a duty of care to to your customers - even if they don't understand the relevance / technical merit. Most people use the same password (and username) across multiple services. Hence not using SSL you are potentially exposing this information.

Yes, SSL hurts performance (a lot).

While just running the authentication over HTTPS would avoid the performance problem, there's still a risk of session takeover - an imposter might post a defamatory comment which appears to come from someone else. Although there are other risk mitigation approaches for this (terms and conditions, publishing takedown policies etc).

Answer 5

The reason that you would want to use SSL to encrypt traffic to your site is to protect the users data and integrity and in return will give the site more validity by having a better reputation.

It's obvious what's wrong with users getting data such as bank or credit card info but there are some less obvious things which are transmitted as well which you would want to keep secure. Getting someones email address not only allows someone to send you spam, it allows an attacker to trace accounts across multiple unaffiliated websites and makes the user susceptible to targeted APT attacks. Getting someones phone number or address can lead to identity fraud and the risk of falling for it is even greater because you now know some of the targets interests (i almost fell victim to it a couple weeks ago because someone had my phone number, a mismatch of my current address and old address, and knew that I wanted FIOS in my city).

Then there's the username and password. Like an email a username can help an attacker trace accounts across multiple sites but could also allow for attackers to pose as their target on other sites (ok so this is a stretch since usernames are usually shown when posting anything on say a forum). Passwords are of course the worst part, possibly even worse than the credit cards themselves. Many people reuse their password across multiple sites, even the important ones. Someone may get a users password from your site, get access to their email because of that password and then charge up tens of thousands of dollars across multiple credit cards, debit cards and checking accounts at amazon because they now have access to the users email account. All this because you (your clients) didn't want to spend an extra few dollars for an ssl certificate (or even get it free of cost).

Then there's the integrity part. If attackers (spammers mainly) can get access to your users accounts, they can post spam (or even launch identity attacks against other users) all across your site causing it to lose any reputation among visitors and drop in any google rankings. You wouldn't simply be able to ban these users/comments because they're coming from existing accounts so you would be banning real users because you couldn't create a secure site.