If you have a website with no customer data do you really need a ssl certificate

[Jester]

I have a few websites, these sites are one way in the sense that the outside world can view them, but I don't have any user input to purchase anything or a database of customer or client info etc.

There is a page with email address, that's it.

Do I really need a SSL certificate and the fees GoDaddy is charging for them?

[mikeselectricstuff]

Depends what you mean by "need" - it will work fine without.

You might find some systems and/or browsers start giving "insecure" warnings.

I'd be interested in any input from more web-savvy peeps on this.

I also run a small SMF forum on a non-HTTPS site - is this likely to be a problem ?

[pqass]

As long as you have control over the domain then https://letsencrypt.org/ will give you a certificate for free.
The certificate is only for 3 months but there are many software tools/methods to automate the request/update.
Your hosting provider may also have capability bultin to the managment console so it can be setup and forget.

[Jester]

I found another provider that gives free SSL service, GoDaddy is charging $99/year

The cPanel fee is also way less expensive.  I think GoDaddy prices have gone up a lot over the last 10 years.

Looks like I will be migrating and saving enough per year to buy a used Fluke DMM, money better spent.

[golden_labels]

Someone has already mentioned Let’s Encrypt. There is no reason to not have TLS nowadays, considering the only cost is setting up the certbot and including certificate deployment verification into normal website monitoring routines.

This is where this answer could end. But there is more to say. The way you asked the question indicates you are having a wrong perspective on TLS. In a manner many people get TLS very wrong: associating security with transmitting data they perceive as “secret”, where the choice of “secret” is often not even well-founded. You need to shift your perspective, because that way of understanding TLS is turning it into a security theater that doesn’t actually work.

First and foremost, before encryption is even considered: TLS offers authentication of your server to the client. A thing without which encryption couldn’t work. It protects your data from attacks. This way you are sure that whatever user sees, when using your website’s address, is what you sent them. They read your text. They see your images. They run your code. Whatever link they follow, it’s the link you offered to them and not something replaced by other actors (and later blamed on you). Attacks that replace contents of websites are becoming increasingly rare in recent years, but having a rogue access point in a venue or a hotel replacing content with advertisements or links to malware is not unheard of.

The reason it becomes rare is: TLS becomes the norm. This is the second point: normalization. The point of having TLS everywhere is not encrypting some “secret” information. The point is creating an environment, in which endpoints may talk to each other as if there was no intermediate actors, and making that the norm. The default. It can not work otherwise. I will stress that: it. can. not. Encrypting a login form or a page displaying personal information doesn’t matter, if links leading to those are on a page sent without TLS.⁽¹⁾ That is a common mistake in deploying encryption by people, who perceive encryption as requiring a special reason to be used. You may as well not bother at all: it doesn’t provide much protection against anything other than passive listening.⁽²⁾ Even if a particular website doesn’t directly benefit encryption, whether it use one affects general security by both technical and sociological means.

Finally, it’s not only about security regarding some particular kind of data. There are things called freedom and privacy. While I do not require anyone to value those, consider respecting that others do and they want to limit exposure. By using TLS you ensure⁽³⁾ that the communication is between your user and you, and potentially anyone you allowed to participate in that exchange. You may think that you do not process any customer’s data. But you do and it’s usually much more valuable in financial terms than their name and address.

⁽¹⁾ All that is needed to strip protection is changing the on the unprotected site. “Please check if there is a padlock” doesn’t work. Not only it ignores psychology — users will not do that or at some point forget to do that — but relies on some weird assumption that an attackers can’t use encryption for their own servers.
⁽²⁾ Which ceased to be a threat considerably greater than data manipulation probably in late 2000s, with routers and advanced switches replacing repeaters in LANs. Right now deploying an attack that modifies data on the fly is not much harder than a passive logger.
⁽³⁾ Limited by assumption of the CA not giving out fake certificates.

[Nominal Animal]

I also run a small SMF forum on a non-HTTPS site - is this likely to be a problem ?

Without TLS (HTTPS), user logins and passwords are transferred in cleartext, and not at all difficult to sniff (more on this below).  I will not use a password on a site that does not use HTTPS for the login part, and seriously recommend the same to others.

(I have done security-sensitive web-based login systems and especially the backend stuff.  Also web site engines and such in PHP and Python.  I write my own from scratch, without frameworks, because I know how to make them very intrusion-resistant.  I used to do this for a while as a job, for both companies and larger organizations like universities.  When I look at the source code and configuration of open source forums, I weep.  No, they're not good.  They work, usually, but that's about it.)

TLS (as used currently for HTTPS) encrypts the traffic both ways, so that sniffing ("overhearing") the traffic is no longer useful, unless you can somehow find out the temporary encryption key used.  (Typically, this is done by either compromising or faking one end, for example by getting a certificate that makes the client believe they're connecting to the correct server, and then proxying the traffic between the fake server to the real server, as if the fake server was the actual client.)

Unprotected traffic is sent in cleartext.  For example, your username and password are sent as HTTP POST data.  If an attacker manages to subvert any of the machines along the data path between the client and the server, they can observe all unencrypted traffic between the two.  Typically, it is the router nearest to the client that is subverted; those things have very little security.  Sometimes, the web hosting provider isn't very diligent, and a lucky attacker renting virtual servers from the same provider can sometimes see some of the traffic to the web hosts; but this is mostly a problem with very fast growing providers who cut corners and don't pay enough attention to information security.

What's the difference between using HTTP and HTTPS, if my own router was compromised, then?

In the case of HTTPS, the attacker also needs a fake certificate, to be able to fool the client to divulge the TLS encryption key.  The attacker may also intercept unencrypted SMTP and IMAP connections, to insert/inject malicious payload attachments to subvert other computers via email, unless those are TLS-encrypted also.  (I use IMAP with a dedicated TLS port; the STARTTLS stuff may be subvertable by a man-in-the-middle.)

Usually, private routers just participate in spamming and DDOS attacks, because encryption is so commonplace nowadays.  But, without the fake certificate, which are neither cheap or easy to come by (and are rather quickly killed by revocation when found in the wild –– the user's don't usually even notice this stuff), it is more a matter of causing issues for others rather than to the owner of the router.  (Which is also why so many routers do get compromised.)

Without TLS, the compromised router can easily see and manipulate everything transmitted without encryption.  It is also rather simple to set up a filter to grab only HTTP traffic when username or password also appears nearby, to help with username + password harvesting.  How often the attackers actually do that, I don't know; that sort of statistics are typically only known to security specialists at larger, well-known antivirus/infosec companies.

I use Let's Encrypt for my own minimal home page.  Feel free to open that page, then click on the lock icon, and check its certificate info.  I currently use OVH for my webhost (simple web site, not a virtual server), and they include Let's Encrypt certificates even on the cheapest (2€/month) hosting services.

Let's Encrypt is an interesting automated service.  The way OVH uses Let's Encrypt is interesting, and is possible for other web hosts to do.  Other domain owners can set up their own, too; just see the docs for the options.  But obviously the easiest and most robust way to do it is to choose a hosting provider that does that for you already, because that way the certificate updates etc. are automatic once the trust relationships have been set up.  I like it.  For a commercial business, I would get a certificate from a commercial partner, one that cares about privacy and security, and does NOT have a history of "accidentally" putting out unauthorized certificates "due to human error".  (That's how crooks get their fake certificates: they buy them from people with necessary access at certificate authority companies.)

[Fredderic]

First and foremost, before encryption is even considered: TLS offers authentication of your server to the client. A thing without which encryption couldn’t work. It protects your data from attacks. This way you are sure that whatever user sees, when using your website’s address, is what you sent them. They read your text. They see your images. They run your code. Whatever link they follow, it’s the link you offered to them and not something replaced by other actors (and later blamed on you). Attacks that replace contents of websites are becoming increasingly rare in recent years, but having a rogue access point in a venue or a hotel replacing content with advertisements or links to malware is not unheard of.

This, so much!

The hotel or other shared internet connection is a huge reason; malware and advert injection into other peoples pages is a big problem.  (Malware getting into advertisers which then get faithfully distributed with the page too — that's happened to a couple banks, no less, though that's a totally separate issue, and securing your page won't help there.)  There was an ISP that was injecting their own advertising into pages their customers were looking at not so long ago, replacing ads already on the pages, and adding extras of their own.  That both robs the original site of advertising money (sometimes it even costs them money because they're paying out for advertising that aren't being seen), and the ISP's own source of advertising was, dubious.  So even without an evil hacker trying to spread malware and stuff, it's been seen out and about.  And there have been cases of hotels or other public internet access points doing the same kind of thing to generate a small return revenue stream on the access they're already providing (particularly "free" internet access, but paid hotel internet access isn't always immune either).  So even if you don't have any ads on your page, if it's unsecured, some of your customers might be seeing ads anyhow — and those ads which you have zero knowledge or control over, are feeding on (and potentially ruining) whatever name and good will you have with your customer base.  Another source of malware, are the fake charging points that sometimes appear places, often with free wifi.  Some suburban parks offer free wifi, many shopping centres, etc..  But someone sitting there with a wifi repeater putting out a better-named access point, and who happens to be closer to you than said access point so theirs comes up on the list first (and maybe putting out a bunch of fake access points to push the real one further down the page, it's pretty trivial to do), can make themselves a middle-man in the traffic, and do that malware injection — another common trick for a while (if not still), was loading in a bitcoin miner script into any unsecured page that flies past.  (In such situations a lot of people are on their hones, with a smaller screen, makes checking these things more effort, and less likely.)  It's just one line added to the page…  The person probably won't even notice, unless they notice their laptop or phone getting unusually hot, and their battery plummeting.  (Why is your page using so much power?!?)

Those cases — probably the most common these days — aren't about attacking you or your data in any way, they're about someone else adding their own revenue stream to your page, under your name and reputation.  They don't even have to know you exist, they just see a request for an unsecured page fly by, and pounce on it with one of several fully automated tools that are readily available (and even free, if you just know where to look — or know someone who knows someone who does), with zero regard to who's page it is, or what content it's carrying.

And as pointed out in golden's response, the connection needs to be protected from the get-go.  Once the protection drops, even just for one page, a man-in-the-middle can seize that page and strip attempts to add https later (in fact, that's probably pretty standard and default setting in most man-in-the-middle attack packages — literally some school kid with a portable access point can do it, it's not big hacker cred stuff), including logins if you were doing any of that.  They can even substitute their own "security" so the page looks secured to a cursory glance (the weirdo free certificate will give that away, if you actually bother to check).

Also, in addition to all the security stuff, apparently google page ranking and the likes give you bonus browny points for using https as well, if any if that matters to you.

[JohanH]

As other pointed out, it makes your site look more professional. I might hesitate doing business with someone that has a plain html page. Now not everyone understand the nuances and I myself is technical enough to understand that a plain html page isn't that dangerous, other than it could in theory be man-in-the-middled and show something else to me. Most important is that modern web browsers are warning that the site isn't secure and they are even beginning to refusing to connect.

Highly recommended to use Letsencrypt. I use it on the web pages that I run publicly (but I run my own linux web servers and use letsencrypt command line client (acme client) to automate the process, so I can't advise about web hosting providers).

[bitwelder]

In addition to all what has been already said, one more advantage of protecting website (especially a commercial one) with TLS is the 'Google page ranking' factor.
As Google has been since long time a promoter of better web security, it also 'rewards' websites using TLS with a higher page ranking, i.e. Google searches will show those websites towards the first results.

That said, unless there is a compelling reason to e.g. buy an 'Extended Validation certificate' (where the seller of the TLS certificate takes care of verifying that the buyer is a real business, that resides at the address stated in the request, etc.), it should be perfectly OK to use a free 'Let's Encrypt' certificate (BTW: those certificates are called 'Domain Validation', as the only thing that is checked is that the cert owner is 'in control' of the domain).
Unless the 3-months LetsEncrypt renewal cycle is too cumbersome to handle, there is no big reason to buy (1-year) DV certificates from GoDaddy or other vendors.

[Bud]

@OP you may certainly lose part of targeted audience because people do not want to constantly deal with security warnings that web browsers give them when connecting to non-https web sites.
Talk to your web hosting provider, they may install a certificate for free, sometime you just need to ask them.

[madires]

Or in short, it's not required but recommended. The dev teams of web broswers think it's a good idea to unsettle users about non-TLS websites or selfsigned certs, despite some CAs are doing bad or stupid things, and you don't get certs for private IP addresses. It's also easy to screw up the TLS configuration , i.e. to allow old and insecure SSL/TLS versions and ciphers. So https provides some sort of security but it's not bullet proof. If your hosting provider/solution supports free certs like Let's Encrypt go for it and don't waste money on expensive CAs.

[golden_labels]

As for the difference between EV and DV (extended validation, domain validation) certificates: cryptographically there is none. A TLS connection using an EV certificate is in technical terms no better than one using a DV certificate from Let’s Encrypt. The difference between EV and DV is in what is being verified.

DV certificates indicate that the domain is actually controlled by the entity requesting a certificate. Using eevblog.com as an example, the certificate says “we checked that whoever asked for that certificate is in control of eevblog.com”. That test can be fully automatic, near zero cost and completely transparent. In fact there is no incentive for the CA to not perform the test, because faking it does not reduce costs.

EV certificates indicate that the CA promises,⁽¹⁾ that they performed additional check: if the entity requesting a certificate is a company named FooBar and located at some address. That is useful only if the user views the certificate during each website visit and checks, if the information match the expected. How often do you open certificate window in your browser and do that? I believe that I could leave you with that rhetorical question.

However, I will not: that coffin needs one more nail. International nature of the internet and complex organizational structures put that task somewhere between cumbersome and impossible. The user is unlikely to remember physical location of the company and even less likely to follow changes in that value. Even worse: company names are not unique. Attacks using companies with an identical name, but located elsewhere, has been successfully conducted.

⁽¹⁾ And let me stress that word: promise. There is not way to tell if they actually do, while the incentive to not be too diligent with the procedure is present.

[Synthtech]

I found another provider that gives free SSL service, GoDaddy is charging $99/year

The cPanel fee is also way less expensive.  I think GoDaddy prices have gone up a lot over the last 10 years.

Looks like I will be migrating and saving enough per year to buy a used Fluke DMM, money better spent.

I agree, Godaddy and it’s proxy businesses have priced themselves out of the market, they are getting a bit predatory in my experience. They do have excellent customer support though. I am looking to move my hosting and domains away from them.

[ejeffrey]

I understand that hosting providers often charge for absurd things but IMO there is no reason for unencrypted HTTP on the public Internet and ideally all servers should have HSTS headers with a long expiration date.  The computation overhead is negligible and Let's encrypt makes it free, easy, and automated so even for a simple static site there is no real downside other than if your hosting providers makes it unnecessarily complex or expensive to enable.  Simply protecting your site from ad injection by your visitor's ISP is reason enough ignoring the privacy and security advantages.

I consider a hosting provider that doesn't make this free and easy to be defective and if I were a hosting provider it would be on by default with justification needed to enable plain HTTP serving beyond an automated redirect.

[ejeffrey]

Or in short, it's not required but recommended. The dev teams of web broswers think it's a good idea to unsettle users about non-TLS websites or selfsigned certs, despite some CAs are doing bad or stupid things, and you don't get certs for private IP addresses. It's also easy to screw up the TLS configuration , i.e. to allow old and insecure SSL/TLS versions and ciphers. So https provides some sort of security but it's not bullet proof. If your hosting provider/solution supports free certs like Let's Encrypt go for it and don't waste money on expensive CAs.

Definitely not bullet proof but there are some mitigations against those problems.  A CA that regularly or systematically abuses their privileges will have their root removed from browsers.  Properly set up DNS CAA records will prevent well intentioned but poorly operated CAs from issuing bogus certificates and also help in uncovering malicious CAs.  https://www.ssllabs.com/ssltest/ will test and score your public site for using strong protocols and ciphers.  Turnkey providers should be able to make the whole thing easy to set up, if you are self-hosting then it is a bit complicated but that is kind of what you sign up for when you run your own web server.

Unfortunately there is no good solution for private IPs.  It is my opinion that browsers should accept self signed certificates for local services without displaying warnings but also without indicating any security.  But there doesn't see to be a lot of push to do this.  It's also a bit tricky: a router that creates a new self signed certificate when powered on is OK.  One that ships with a non-unique self signed certificate created by the manufacturer is worthless but a browser has no way to tell the difference.  Big organizations can run internal CAs and install the root in their standard system image but that's not really a feasible option for home and small office users.

[cdev]

Google, etc. as part of their corporations take over the world agenda, seem to be trying to scare people away from non-ssl websites - secured with commercial providers, a self signed certificate isnt enough for them to not use scary messages.

I suspect they are trying to conceal problems with the TLS model. I think the default should be not trusting certificates, unless you decide to trust them., Globally. 

[cdev]

@ejeffrey,

that wouldnt be so difficult if all your home machine run the same linux distro, but as you said, you would have to make your own install DVD and always use it, then update it and all your machines at the same time. Or something like that.

Thats what most large organizations do.

[golden_labels]

ejeffrey
If we limit the talk to hosting providers only, charging for being able to deploy a certificate is a typical case of artificial scarcity tactics.

But the other extreme — unsolicited deployment with enforced HSTS — is risky. While I see HTTPS as something that should be the default, it’s not a binary parameter that can be simply turned on and off. There is a bunch of choices to be made, which affect where the service ends up on the availability-security axis. Go too strict and you will get an A+ from Qualys, but cut off 5–10% of the population with older clients. Be too lenient and you get a pretense of security. Setup renewal and monitoring wrong and join the ever-growing club of people, who received a message “Dear Organization, I think your certificate expired a week ago”.

This can be addressed and I hope it will. It must if hostings wish to support HTTP/2 and HTTP/3.⁽¹⁾ I will suggest using TLS whenever possible. But I am all too well aware of how a mix of inexperienced people, lack of diligence, poor advice, cutting costs, abusing position and a somewhat complicated matter is a recipe for a disaster. That makes me see offering a free option to enable HTTPS, possibly even suggested, as a good solution for now.

cdev:
I’m not sure if I even should respond to a conspiracy theory peddling, but since someone may read it and believe: self-signed certificates are useless in practice for web deployment⁽²⁾ and it has nothing to do with some organization taking over anything. A connection authenticated and secured using a self-signed certificate is as good as any other — that’s true. That is because the public key is still perfectly good for cryptographical purposes. But the certificate part of the certificate might as well be non-existent.

The very purpose of a certificate in a public-key cryptography system, the reason why one ever wants a certificate, is proving that a third party has signed that key. If there is no third party involved, there is no certificate. It is technically still using the same storage format, but the signature part is not doing anything. It’s a public key with garbage attached to satisfy programs.

That key alone can still be confirmed to be valid. But that requires the user to contact the server owner through a secured channel and verify if the fingerprint agrees. That is not merely cumbersome, but usually impractical. It’s so impractical that people promoting such ideas are rarely doing that themselves even in contexts where verification is quite easy. The solution would be to make someone else do that confirmation and pass you the information securely, which… ohh… you have just discovered ceritficates and CAs!

But that’s not where the problems end. There come issues of psychological and social nature.  A TLS certificate may be valid for domains other than the one one is visiting.⁽³⁾ Unless the client prevents such attacks or CAA records are present and acquired through DoH, the user must verify the subject or is allowing the issuer to strip protection from connections to other services. That is being done even more rarely than checking the fingerprint.⁽⁴⁾ Finally, if deployed as a replacement for CA-signed certificates, that would be an environment where the user is facing a message of that kind on every website they visit: “please accept this certificate, we are assuring you it’s fine”. It’s a security anti-pattern by itself and users simply clicking-through those messages without thinkking is making it even worse. You could as well not have TLS at all at this point, as poisoning such a broken environment is a piece of cake.

⁽¹⁾ Stricly speaking HTTP/2 may be used without encryption, but no popular browser supports that mode.
⁽²⁾ They are useful in closed environments, e.g. in corporate networks.
⁽³⁾ Which by itself is a valid use case, so it can’t be considered suspicious.
⁽⁴⁾ Which is funny, as promoters of self-signed certs are often citing “CA may be rogue” as an important argument, yet somehow assume that a bunch of totally random people on the internet can not.

[capt bullshot]

I have a few websites, these sites are one way in the sense that the outside world can view them, but I don't have any user input to purchase anything or a database of customer or client info etc.

There is a page with email address, that's it.

Do I really need a SSL certificate and the fees GoDaddy is charging for them?

Simple answer: No.

[ejeffrey]

ejeffrey
If we limit the talk to hosting providers only, charging for being able to deploy a certificate is a typical case of artificial scarcity tactics.

I get why they do it.  I think it is stupid and dangerous, and I think that nobody should do business with companies that behave this way.

But the other extreme — unsolicited deployment with enforced HSTS — is risky. While I see HTTPS as something that should be the default, it’s not a binary parameter that can be simply turned on and off. There is a bunch of choices to be made, which affect where the service ends up on the availability-security axis. Go too strict and you will get an A+ from Qualys, but cut off 5–10% of the population with older clients. Be too lenient and you get a pretense of security. Setup renewal and monitoring wrong and join the ever-growing club of people, who received a message “Dear Organization, I think your certificate expired a week ago”.

There are reasonable default configurations that will work for 99% of clients and provide pretty good security.   And frankly I don't think that catering to IE7 on windows XP is an acceptable argument for not making mandatory TLS the default behavior.  I wouldn't go so far as to prevent opt-out, but there are an extremely small number of cases where a default TLS setup would not be a good choice and I think it is totally OK to make people who need that functionality select it explicitly and let everyone else get strong encryption by default.  Incorrect renewal settings and expired certificates are a problem but in the context of managed web hosting providers that is a service they should provide in the default configuration.  For people administering their own server it is more work, but that is part of the job.

[ejeffrey]

ejeffrey
But the other extreme — unsolicited deployment with enforced HSTS

Also: to be clear, I don't think hosting providers should enable HSTS by default in most situations.  I think hosting services should operate TLS-only by default and then make it easy to turn HSTS on when ready.  I might change my stance on that in the future for for the moment I agree that automatic HSTS is too risky even though the benefits are very real.

[golden_labels]

To be clear, the outdated clients is not IE7. That’s smartphone users.

[Nominal Animal]

FWIW, I have TLS enabled but without Strict-Transport-Security headers (HSTS).  I do not have any user information there, or anything not-public, and there are no security implications even if someone accesses the site without encryption.

So, my opinion is that when there is no actual need for TLS encryption –– like keeping user information private ––, supporting TLS encryption (https) is a good idea, but there is no need to enforce it with HSTS.

If you have something like a login form or restricted pages or non-public information anywhere on the site, then HSTS is recommended/necessary.

[madires]

If you want to make things harder for the bad guys also set up DNSSEC for your domain and use DANE. And add RRs to state which CA is allowed to issue certs.