Anyone know anything about renting servers?

[phantomotap]

HTTPS does not enhance privacy and reduce security risks in all cases

O_o

If you have a couple of hours to look around, you can easily prove to yourself that HTTPS alone isn't such a beast in any cases.

Many data breaches the last few years were managed thanks to fools sprinkling a little HTTPS over their infrastructure without a thought to apply the vast number of other industry standards for security.

A couple of ridiculously common examples:

$): Some places still have passwords limited to eight characters...
$): Using a very simple, pure increment, "session stay" in cookies...
$): Reusing user passwords for administrative roles...
$): Never updating the software stack to patch known exploits...

*shrug*

These days people seem to mix and match what security practices to follow when you need them all just to stay evenly matched.

Soma

[Elysia]

Also, I am not predicating that all you need to protect your site is sprinkle some TLS a little here and there. That's not security. All I'm arguing is that HTTPS should be part of the basic security of any site. You need to fill in the proper security policies yourself after that, depending on the needs of your site. But you should have at least TLS.

[bithub]

It is never a bad idea to use HTTPS for your website (with a properly signed certificate). Once we get to a point where getting signed certs is free, there will be no excuse to run a website over HTTP.

[whiteflags]

Also, I am not predicating that all you need to protect your site is sprinkle some TLS a little here and there. That's not security. All I'm arguing is that HTTPS should be part of the basic security of any site. You need to fill in the proper security policies yourself after that, depending on the needs of your site. But you should have at least TLS.

But the crux of the disagreement is that if you are essentially serving the same content to everyone, then there is no reason to use https because there is nothing to steal... no password authentication, no purchasing (and the processing of credit cards entailed therin) or member-specific content like emails, etc.

When you say any site you literally mean this is pixie dust that will automatically make a site more secure because --

Of course it doesn't work for all cases, but in general,
Let A be the set of all possible connections to web pages and B be the set of all possible secured connections (to the same servers as in A).
Let S be a function that takes a set and returns a subset with all vulnerable connections. Then, it holds that
|S(B)| < |S(A)|

logically (?) there are more vulnerable connections than secure ones.

That is not a security rationale. What are you trying to secure? How does https help? You don't know? You're fired.*

*These are rhetorical questions. I'm just saying, any rational effort to secure something starts with knowledge of what you're securing and how a process or technical thing will help. You don't supply that when you just say "do it all the time".

[Mario F.]

There's a trend going on for a couple of years in the internet that defends websites should all start adopting HTTPS. It's a particularly strong sentiment among privacy advocates.

HTTPS is not a complicated protocol. All it does is ensuring privacy by means of encryption. I can "speak" with a website without anyone being able to understand our dialog. It's an appealing concept that models what we usually want when engaging in verbal and written communication in real life. Under many situations I wouldn't want the post office to open my letters, or someone to eavesdrop when I'm talking with my wife.

There's nothing particularly troubling about this. Or complicated in the face of it. So, I would say, yeah go for it. If you can afford it, go HTTPS.

But it's more complicated than that. The HTTPS infrastructure, due to its piggybacking nature, suffers from many of the security flaws of HTTP. In particular, the web developer needs to go through a whole lot of trouble to ensure proper security, that involves every aspect of their website, down even to its data workflow. For more information, see this paper (PDF). It's exactly the type of false sense of security Laserlight was alluding to.

To make matters worse, the whole service infrastructure being around HTTPS is a complete mess, with web browsers not agreeing at all on a standard response to malformed HTTPS (by malformed I mean everything, from pages with partial insecure content, to the decision on which certificate providers to trust). In fact, the choice for public key encryption is exactly what makes it such a mess to consider and the reason for why this is not going to become a ubiquitous communications protocol in the internet, despite Elysia's desire. Certificates cost money, that's one problem for anyone envisioning a world in which every mum-and-dad's website runs on HTTPS. They are charged annually that's another problem. But more technically, certificate authorities are themselves excellent candidates for man-in-the-middle attacks, becoming a weak link for anyone wishing to disrupt the service or take advantage of it. VeriSign and DigiNotar are two recent cases, from as close as 3 and 2 years ago, of certificate authorities that got hacked and ended up issuing rogue certificates.

The whole browser trust process has become a burden to both web developers wishing to implement HTTPS and certificate authorities wishing to conduct their business. What's worse, without the commercial edge, certificate authorities have little incentive to issuing and maintaining the life cycle of a certificate (expiring, revoking and whatnot). A free certificate industry is almost certainly doomed to fail for the simple fact that the security concerns that are required by a digital certificate and demanded by its customers require elevated costs to the service provider of those certificates.

All in all, I don't see HTTPS as an ubiquitous protocol in years to come. In fact, I defend that instead of avoiding the real problem, we faced it once and for all. We need instead to come up with a whole new and better request-response protocol that puts the 24 year old HTTP protocol to a good rest.

[bithub]

But the crux of the disagreement is that if you are essentially serving the same content to everyone, then there is no reason to use https

This is not true. The main purpose of using HTTPS is to protect the user of your website.

Without HTTPS, users are vulnerable to MITM attacks. What if a malicious entity intercepted the user's request to your simple website? What if instead of returning your simple website to the user, they returned a malicous copy that attempted to install malware? What if it added a donation box that would send money to the attacker? What if it added a "log in via Facebook" link to the top of your page, but the credentials went to the attacker instead? Javascript is very powerful, and there are a lot of things a bad site can do to steal information or exploit vulnerabilities.

In my opinion, the only valid reason for not using HTTPS is the cost factor. Chrome has already stated that sometime in 2015 it will explicitly mark HTTP websites as insecure as a warning to the user.

[whiteflags]

What if a malicious entity intercepted the user's request to your simple website?

You don't have to protect against MITM attacks with https. There are multiple answers for that, including but not limited to DNSSec.

[bithub]

You don't have to protect against MITM attacks with https. There are multiple answers for that, including but not limited to DNSSec.

DNSSec does not (nor was it ever intended to) prevent MITM attacks, it prevents DNS spoofing.

[whiteflags]

You would have to explain it to me then. DNS spoofing is a kind of MITM attack.

[bithub]

You would have to explain it to me then.

DNSSec ensures that when you do a DNS query, the IP address that you receive is the actual IP address the domain operator placed into the DNS server. It basically performs the same function for DNS that the HTTPS certificate performs for HTTP. All this does is ensure that the user has the correct IP address. A subsequent request for data at that IP address can still be hijacked my a MITM if HTTPS is not used.

[laserlight]

HTTPS is not a complicated protocol. All it does is ensuring privacy by means of encryption.

If that were true, then self-signed certificates would suffice. Rather, it ensures confidentiality with a secure channel in which the client has authenticated the server's identity (and I believe optionally, the other way round too). Consequently, we need Trent, but then we also have to pay him (for now, with the exception of CAs that offer free certificates as Elkvis noted).

EDIT:

All in all, I don't see HTTPS as an ubiquitous protocol in years to come. In fact, I defend that instead of avoiding the real problem, we faced it once and for all. We need instead to come up with a whole new and better request-response protocol that puts the 24 year old HTTP protocol to a good rest.

I'm not sure if that will actually fix the problem: we still would have to establish a secure channel over an insecure network, no? Therefore, public key cryptography and the supporting infrastructure will still come into play for key exchange. It seems to me that such a re-design would just make it "cleaner".

Without HTTPS, users are vulnerable to MITM attacks. What if a malicious entity intercepted the user's request to your simple website? What if instead of returning your simple website to the user, they returned a malicous copy that attempted to install malware? What if it added a donation box that would send money to the attacker? What if it added a "log in via Facebook" link to the top of your page, but the credentials went to the attacker instead? Javascript is very powerful, and there are a lot of things a bad site can do to steal information or exploit vulnerabilities.

Good point. It is plausible since this after all exploits the lack of authentication. That said, such an attacker can do this kind of thing with his/her own website and may be more effective in combination with phishing and other techniques. If you are not making enough money on your ("altruistic") website to cover the additional cost of a certificate, and you are not differentiating between users, then it seems to me that the cost-benefit analysis would show that the certificate is unnecessary.

[brewbuck]

The conversation seems to have gone off field a bit...

My personal recommendation is Linode, they are cheap, reliable, you get full root access to your box, and they are very responsive (IME). I barely even notice that I'm paying for it.

[MutantJohn]

The conversation seems to have gone off field a bit...

My personal recommendation is Linode, they are cheap, reliable, you get full root access to your box, and they are very responsive (IME). I barely even notice that I'm paying for it.

Thank you for the recommendation. I'll be sure to check them out.

[Epy]

DigitalOcean is good as well (very similar to Linode), but I would say probably check out Linode first because DigitalOcean gets nasty with you if you use 100% CPU 24 hours a day...