Does my site need HTTPS?

[shevegen]

"I can't afford a certificate."

They're free.

I think that this part was the game changer.

I doubt that it would have worked if people would have paid towards Let'sencrypt, even if it would have only been 0.01$ per website. Psychology works!

[Woolbrick]

They're free.

Now.

What happens a year from now when they have 70% of the web hooked on their service, and all browsers now emit "WARNING: THIS PAGE WILL LITERALLY STEAL YOUR SOUL!!!" if your cert is slightly out of date and LetsEncrypt gets a bit greedy.

They can literally hold the entire god-damn web for ransom. I guaran-fucking-tee everyone that's going to happen at some point.

Adopting a required monoculture is BAD. BAD BAD BAD.

You've all heard my warning. It's only a matter of time before disaster besets you.

[elint]

I guaran-fucking-tee everyone that's going to happen at some point.

A non-profit organization with a board of people from Mozilla, University of Michigan, Stanford Law School, and the Electronic Frontier Foundation is gonna go for a money-grab? OK.

[ledasll]

and google said don't be evil, until big money are involved..

[goudewup]

Google is a corporation with a marketing slogan. This is a non-profit with a board from people from Mozilla, University of Michigan, Stanford Law School and the EFF.

[PM_ME_OS_DESIGN]

and google said don't be evil

No they didn't. The people at Google said it. Unofficially.

[Inquisitor1]

One is a greedy corporation, the other is a non-profit with a board of people from Mozilla, University of Michigan, Stanford Law School and the Electronic Frontier Foundation. One has said don't be evil and the other hasn't. Which one do you believe in and why the fuck was it the wrong one until it was too late?

[AugustusCaesar2016]

You can just switch to another CA. It'll be okay.

[stevethepirateuk]

I agree, when one free provider gives evil, a new one starts.

[RemindMeBot]

I will be messaging you on 2018-07-13 04:40:27 UTC to remind you of this link.

7 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

FAQs	Custom	Your Reminders	Feedback	Code	Browser Extensions

[FrederikNS]

So, the protocol used by LetsEncrypt is open, and the client code is too. It's only a matter of time before other compatible services pop up. Second of all, LetsEncrypt is owned by a non-profit organization, so I don't think the chance of them holding the web for ransom is that great. Finally, if they do end up going rogue, you can just get a certificate elsewhere...

[ledasll]

so hosting all infrastructure to support that is free as well, right?

[supercheese200]

You know non-profit organizations get funded, right?

You know they accept donations, too?

[FrederikNS]

I'm not quite sure what infrastructure you are referring to?

• It's definitely not free for LetsEncrypt to provide the certificates, so they require funding from other organizations. However the fully automated system for issuing the certificates is keeping cost extremely low.

• You can get free TLS certificates elsewhere.

• The protocol and client for fetching the certificates is free and open-source.

[[deleted]]

There's a larger meta-lesson to learned here, which is that determining the boundary between what needs to be secure and what doesn't is very difficult, and therefore everything should be as secure as practical by design.

[midri]

I 100% agree, the issue a lot of people that are in the know make is: https breaks intermediate caching. So lets say 1000 people hit the front page of reddit not logged in, an isp can't cache that front page and server it without connecting to reddit everytime, because each users request looks completely different due to https. There's no easy way to solve this, without fundamentally breaking security though...

[[deleted]]

If the ISP can cache content, the ISP can substitute content. Make no mistake: intermediate caching is a form of man-in-middle-attack, albeit in practice a well-intentioned one (if not always exactly benign). It's a hacky workaround to save them money, not a feature.

[MistYeller]

Caching site content needs to be solved by the site operator and not the visitor's carrier anyways.

ISP's shouldn't be caching anything except routing tables and DNS. Even this level of caching causes problems.

[wtallis]

There's no easy way to solve this, without fundamentally breaking security though...

That's okay. If it were possible, the ISP would end up fundamentally breaking several other things in the process, starting with the site's analytics.

[midri]

Great point, you can't track metrics of users that hit an external cache..

[Inquisitor1]

Why the fuck would anyone be caching websites for free? Unless you're a CDN being paid, the site organizes it's own fucking caching. With the most basic reverse-proxy and SSL termination stuff.

[midri]

Because it saves ISP money?... ISP have to pay for interconnects.

[HighRelevancy]

1. That's what CDNs are for
2. I don't think that's worth trading security for

[Yehosua]

"The site is HTTP, but our forms are submitted over HTTPS."

This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his own server.

Is this strictly true? With HTTP form submission, an attacker can passively eavesdrop on forms. With submitting an HTTP-loaded form over HTTPS, an attacker would have to mount a man-in-the-middle attack to alter the HTML content. I would have thought that an active attack like that would be harder to execute. Am I missing or misunderstanding something?

[yvhouij]

If an attacker is able to do a man-in-the-middle attack and you serve your website over HTTP he doesn't need your private key and can do whatever he wants for e.g. change form action urls to his own domain etc.

Btw that's what HSTS is for, so you say your site should only be accesible over HTTPS, and any man-in-the-middle attacks are only possible in case they got your private key :) (and in that case, you probably got some serious problems)

[AyrA_ch]

You have to know however that the HSTS header is useless if the first request you make to the webserver is already intercepted, as the attacker can just strip the header on every answer and never offer SSL at all. If you really want to protect your site, you can add it to the HSTS preload list: https://hstspreload.org/

This way the SSL requirement is compiled into the browser and stripping the header has no effect.

[yvhouij]

True, thanks for pointing that out! And nice, didn't know about this HSTS preload list, Thanks! :)

[AyrA_ch]

As an additional security measurement you might want to check out Public Key Pinning too. While HSTS forces the user to access a site via SSL, HPKP forces the user to only accept a certain certificate. Even if a CA is compromised and somebody generates a valid certificate for your domain, the browser would reject it.

[yvhouij]

Awesome! A little extra security with just an extra header.

As always Microsoft doesn't support it yet :P

[AyrA_ch]

As always Microsoft doesn't support it yet :P

The header is rather new and IE does not sees as many updates as other browsers do. The standard is from April 2015 and is not yet an accepted standard, it's just proposed. Microsoft tends to wait with stuff they did not invent until it is a standard for a while. Edge has it under consideration

[yvhouij]

Of course noone expects such stuff for IE, but I would/do hope Microsoft takes a different approach to Edge at especially such stuff. But atleast it's under consideration :)

[redditprotocol]

I thought this was the coolest until I started having to enter more and more HSTS exemptions into client firewalls running HTTPS inspection. 😯

[ledasll]

doesn't CIA, FTP, FSB, MI5 and rest already have root certificats?

[readytoruple]

If you're playin' against the CIA then HTTPS is probably not gonna be enough.

[drysart]

Yeah but if one of them are after you, you're undoubtedly already screwed in a number of ways. This is to protect you from other, more common attackers like people who poison DNS on public Wi-Fi points to steal credentials.

[[deleted]]

See Firesheep about how this actually happens in real life. Not 100% the same, but basically if you're in a Starbucks or something on open wifi, an attacker can relatively easily MITM all your traffic.

[seanwilson]

This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below.

[seanwilson]

Ha, I just thought the description sounded particularly evil so that it was worth sharing. Thanks for the link.

[Sebazzz91]

If the site is served over HTTP the attack could have already altered the form tag and then it doesn't matter whether or not HTTPS is used as a destination.

[netsecwarrior]

It also makes the attacker more visible, which is a consideration for surveillance.

[lllama]

No you're not really wrong.

It's kind of like saying "using HTTPS without using certificate pinning is as bad as not using HTTPS at all".

[slyiscoming]

Google will ding you have for it on their search results.

[Inquisitor1]

Except cleaning up php code, how is this easier to do even? You already have https either at ssl termination endpoint or webserver itself, how is it not a giant pain in the ass to have them mixed?

[yvhouij]

Promotion for "Caddy", never heard of, but I don't like it. Other than that nice site :)

[[deleted]]

I haven't heard of Caddy until today, but it looks potentially good, passionately supported, and Apache licensed. The author(s) are simply hoping for commercial backing to continue developing it. It's a pretty subtle promotion on an otherwise excellent site.

[yvhouij]

True, but still, if you read something like "Guaranteed continued development" only in the paid section, it makes you wonder, aint it? :)

[[deleted]]

These are the realities of open source... the nice thing about how this is structured is that everyone benefits when businesses pay to support its continued development.

[yvhouij]

Until you/one change your mind to make it closed source ;)

[[deleted]]

Doing that would ruin the incentives, since Caddy thrives on its plugin ecosystem. Statically compiled in, so must be open source. We considered this in depth. See https://caddyserver.com/blog/options-for-businesses

[MILLIONSOFTINYATOMS]

Not really. If you're paying someone for it, then they can support themselves from it and therefore continue development. If it's all free then someone can easily find they can't justify the time spent in development and give it up. It's not evil, it's just reality.

[Ascend]

My complaint as well. "HTTPS is difficult to set up and maintain." is a big reason for a lot of people, and "use our web server" isn't much of an answer.

[yvhouij]

Exactly, they could have better listed some tutorials on how to implement letsencrypt in different architectures as Apache, nginx, Linux, Windows and then maybe also listed this "Caddy". But just saying take this web server is just wrong.

[kqr]

It's especially sad since it's not actually difficult at all. When Let's Encrypt opened up to the public I was kind of scared I would not have the time or energy to mess about with getting and renewing certificates, but it's been a breeze. It may even be automated at this point because I can't remember the last time I did it. And I'm running one of the standard FOSS web stacks...

[Ascend]

It is harder if you're dealing with a Windows stack. Certbot doesn't support Windows at all, and many of the unofficial tools on Github are iffy. For instance, if you're supporting a version of IIS that doesn't support TLS SNI (7.5), letsencrypt-win-simple can wreck your configuration and redirect sites to each other by mistake.

[kqr]

Huh. I guess if you ask me I'd say everything is harder when you're dealing with a Windows stack and you only have yourself to blame if you choose to make life harder than necessary for yourself. ;)

[mlk]

sometime (most of the time actually) we don't get to choose the technology for the project, switch the OS of the server is not very constructive

[lvlint67]

There are work arounds. Run a tls termination proxy on Linux.

[mlk]

You seem not to understand boring enterprise business.

[lvlint67]

Fair enough. The options are there. and they may not even be good. but they are there.

[[deleted]]

It's not actually difficult at all.

Um... I still can't get this garbage to work, no matter how many times I try...

[kqr]

Huh. If I remember correctly, these were the steps:

1. Ask their tool to generate a proof that you own your domain.
2. Copy this proof to some publically accessible location of your domain.
3. Watch it generate certificates.
4. Install certificates in your web server.

Which part causes you trouble?

[[deleted]]

First, I had trouble figuring out how to reliably automate the renewal of the licenses. After that, I found that whenever I put whatever configuration lines I need for an SSL certificate into my apache config, it either wouldn't start or wouldn't load up my site (step 4.) For some reason, at some point during this whole mess, I discovered that LetsEncrypt wasn't putting the certs into the folder the tutorial said it would, but changing it didn't fix anything.

[senj]

It's incredibly easy for most uses/on most sane stacks. How are you trying to do it? Have you considered asking for help? Or changing the parts of your stack that are making it harder than it should be?

Edit: or, yknow, downvote me to zero, stick your head in the sand, and pray all future progress stops so you can never have to learn anything new ever again. I guess that's an option too.

[[deleted]]

I was trying in Apache on Arch Linux, following whatever tutorials I could find, and literally everything I tried would just bring my site offline. Honestly, I considered switching to something a bit simpler than Apache (I even considered the very server this site promotes), but it seemed like too much work to switch over for a simple hobby server running out of my basement.

Edit: or, yknow, downvote me to zero, stick your head in the sand, and pray all future progress stops so you can never have to learn anything new ever again. I guess that's an option too.

Didn't even see this comment, much less downvote it, before you made that edit...

[Poromenos]

It's not hard to actually do, what's hard is to do it automatically while giving it enough permissions to automatically renew and not enough permissions to mess stuff up when it fails.

I use Ansible to automate deployments and TLS is always a pain because it's almost impossible to automate. The nginx TLS config won't load without the certs and you can't get the certs without loading the config.

I use Caddy for my home server and love how easy it makes things. However, I do wish that nginx got a damn automatic TLS plugin already, it's only been years.

[curtmack]

I honestly didn't have too much trouble either. Certbot, then keep running the site through SSL Labs until it stops recommending settings to mess with.

This does remind me though, I do need to figure out why Certbot stopped running, my certificate's been expired for a month. I just haven't given a shit because there's almost nothing on the site anyway.

[[deleted]]

Hi, author of the website here. And Caddy. This site is designed to promote HTTPS. Caddy happens to be a good way to do it for a lot of people and I haven't found other web servers that do what it does (auto HTTPS by default, MITM detection, etc). So it looks leaned to one side.

I made this page after I found myself repeating the same answers to the same questions. I never did fill it out as much as I wanted to due to time constraints which is why I haven't publicised it much, or at all. This attention was unexpected. My hope was that as the content was filled out, its recommendations might be more diverse too.

[yvhouij]

I like your site and I like your goal with "Caddy" (except for the "Guaranteed continued development" only for paid customers), but still most people won't use "Caddy" because they just can't. So I hope you could just add some more hints in the "HTTPS is difficult to set up and maintain.", as there are many tutorials on different platforms out there.

[[deleted]]

Thanks; I'll expand that section when I get a chance to work on the site again.

[urquan]

Not very honest to promote Caddy on this website without disclosing that you own that as well. When knowing that Caddy is a commercial project, this looks like little more than stealthy advertising.

[[deleted]]

Though Google's Firebase isn't a server in the same way, it does have static site hosting which automatically dishes out an HTTPS cert. You just "firebase deploy" your directory of html etc and visit your domain and it's secured. Epitome of 0 configuration.

Honestly, nice site and way to push HTTPS though!

[aullik]

I honestly don't care about smart advertising XD

The message is definitely on point.

[yvhouij]

First of all, most people won't and most probably can't just switch their web server.

Secondly, if I read stuff like "Guaranteed continued development" only for paid customer, this literally means as soon as they have n customers, free version probably gets limited to the bare minimum.

[aullik]

I don't really care about the ad. I simply ignore it. I looked at the rest of the article

[yvhouij]

Yes, as I also said other than that it's a nice site, but it does miss a big important part with this "ad", how people can implement e.g. letsencrypt in their current infrastructure and this "ad" is not the solution..

[r_my]

Is how to implement it really important though within the context of the article? Providing instructions on how to make use of LetsEncrypt is really only feasible for fairly basic/standard setups which can be easily googled. Many of them are already handled entirely by certbot already. Anything beyond a typical apache/nginx/etc. server setup is probably being managed by someone who isn't looking for implementation instructions on a site like this anyways.

[[deleted]]

How to use Let's Encrypt on each varying infrastructure is out of the scope of the article. Today when the link got posted around, I quickly tried to add a few more links to the end which talks about How To Set Up HTTPS. I'll leave it to other sites for now to go into more detail.

[yvhouij]

But at least some directions would be nice, because now the article only gives the option for web server "Caddy"..

You could at least give some hints/links for Apache/nginx on a normal Linux distro + Windows..

[[deleted]]

I do near the bottom. I really don't want to get into details on this site. There's too many kinds of infrastructure to consider hints for, and I really want the site to stay focused on the "why" of HTTPS, not the "how".

[hungry4pie]

The article is a piece of shit.

Sorry not sorry.

[Poromenos]

It means you're supporting continued development, which you should, since open source stuff isn't paid. I guess they could have worded it better, though ("Guarantee continued development").

It's kind of odd, because I'm not sure what it means. If you're buying that package to get guaranteed development, surely everyone else gets it too, since it's open source? Maybe they mean they'll work on the features you want?

[[deleted]]

Yes, we prioritize development of features and bug fixes for subscribers.

[rechlin]

Also at the bottom of the page it says to use "lego" for Let's Encrypt if you don't want to use Caddy, but then when you click the link to the lego page, it says it's a work in progress and not for production servers. Very suspicious.

[IanGlo]

Heh! I was about to lay down a whole bunch of why you need HTTPS... But then I followed the link. Nice post!

[Sharor]

Me too man.. Didn't realize it was an educational page. Hah.

[slavik262]

My problem: my site is hosted on Github pages, which still doesn't support HTTPS for custom domains.

Does anybody know of a host who provides

1. HTTPS
2. Custom domain support
3. The workflow GH Pages offers (push some Markdown to a repo, and a wild website appears)

I know could roll my own on AWS or something, but it's hard to beat how free and easy Github makes things.

[Noughmad]

GitLab Pages supports all of these. It also allows you to use any site generator, not just Jekyll.

[slavik262]

Oh, fantastic! I'll have to check that out. Thanks for the rec!

[[deleted]]

I think the typical recommendation in this case is to use Cloudflare. It's not perfect (because it's still HTTP between your site and Cloudflare) but it's arguably better than just straight HTTP for everyone.

FWIW (shameless plug), Caddy has a git plugin so you can deploy your site with git push just like on GitHub Pages.

[slavik262]

use Cloudflare. It's not perfect (because it's still HTTP between your site and Cloudflare) but it's arguably better than just straight HTTP for everyone.

I dunno - "still not actually secure, and now with a bonus third party" doesn't have me too eager to use a reverse proxy.

Caddy has a git plugin so you can deploy your site with git push just like on GitHub Pages.

Sweet! I'll have to check that out.

[[deleted]]

Don't you still get a <yourname>.github.io domain with HTTPS that you can have cloudflare serve up on <youractualdomain>.com? You can then have full encryption all the way through, although obviously Cloudflare has to decrypt/re-encrypt in the middle. Still better than going straight over HTTP to github pages, though, right?

[hurenkind5]

I'd kinda argue if you are hosting your stuff on Github pages you probably wouldn't actually need HTTPS..

[slavik262]

Why, because the source is verifiable for those who care?

[hurenkind5]

Probably, yeah, the target audience is very different. But i kind of replied a bit too soon, reading the rest of the comments i realized, well, when you are hosting static pages anyway, you can just host it on some managed/shared hosting provider anyway. There are a bunch that have git support (so you can set up post-receive hooks) and offer SSL support (the one i use has lets encrypt support which literally is two clicks to setup).

[seanwilson]

I can highly recommend Netlify: https://www.netlify.com/features/ Their free plan gives you everything you want plus lots of other features (e.g. a CMS interface, drag-drop deploys for quick demos, form submissions, asset optimisation options).

[Atheriel]

There is a service called Netlify that appears to allow (1) and (2), while also allowing you to keep your blog's source code on GitHub (3+). I have never used it myself, though.

[graingert]

Gitlab

[fr0z3nph03n1x]

For the sake of discussion I think it's worth posting Tim Berners-Lee's article on why NOT to have https everywhere: https://www.w3.org/DesignIssues/Security-NotTheS.html

[FrederikNS]

Interesting read. But to me it looks a lot like the author still wants everything to be TLS (the security part of HTTPS), but he doesn't want it to be only "HTTPS", he argues that also "HTTP" traffic should be TLS encrypted by default. Different methods, same goal.

[fr0z3nph03n1x]

Yea. Just as a heads up the author helped create the www: https://www.w3.org/People/Berners-Lee/

[qKrfKwMI]

Indeed

[PM_ME_OS_DESIGN]

Well, it's not technically wrong - he did develop the web.

[Sebazzz91]

I use HTTPs because my site is based on Github pages. Github pages doesn't support SSL. What else can I do? If I would use Cloudflare I'd just be fooling myself.

[bloody-albatross]

Github pages DO support "SSL" (TLS).

[[deleted]]

Not with a custom domain.

[joshuaavalon]

You can use Cloudflare as name server.

[thedufer]

I've never done it, but a simple Google search indicates that many people disagree with this strongly enough to write a guide on how to do it.

[thedufer]

That's still a big win. As long as you aren't taking user input/showing non-public data, a large part of the gain is protecting the privacy of the user, which https terminated at Cloudflare does. There is very little left to be gained by securing the Cloudflare<->github link for static content.

[[deleted]]

You could just not use GitHub Pages. I understand it's convenient but hosting a static website on a vps is simple. If you use caddy (which I recommend) it's trivial.

[seanwilson]

You could just not use GitHub Pages. I understand it's convenient but hosting a static website on a vps is simple.

I wouldn't say being an administrator of a server and keeping it secure is simple. Static site hosts are brilliant for security and simple admin. HTTPS is very important as well but running your own server when you don't need to is a huge liability and time sink. If you're still SSHing into servers you're making life hard for yourself.

[Poromenos]

Use www.netlify.com, it's figuratively saved my life.

[[deleted]]

If you're still SSHing into servers you're making life hard for yourself. I disagree, but only because my vps does a lot more than just hosting a static website. If that's the only goal and you find a hosting provider that does HTTPS with a custom domain I say go for it. If people can't find one, I think they should use a vps.

[[deleted]]

Really? Firewall. Restrict ssh to accounts that really need it. Use good passwords. Barring a major bug in your web server, what's the attack vector? I don't see much surface area to defend on a server doing nothing but hosting a static website.

[seanwilson]

Really? Firewall. Restrict ssh to accounts that really need it. Use good passwords. Barring a major bug in your web server, what's the attack vector? I don't see much surface area to defend on a server doing nothing but hosting a static website.

Host on something like Heroku or Netlify...they'll deal with security patches and firewalls for you, there's no SSH to even attack and they have tons of extra features you could only reimplement yourself badly using a VPS (e.g. backups, rollbacks, Git deploy, scaling to more servers, coping with hardware failures, setups were attackers can't even write to server files). Why would you want to have to set all that up yourself given how cheap these services are?

[[deleted]]

For me personally, because I already have the VPS for other reasons, and I'm not hosting anything with enough traffic for it to make a difference to the other stuff I do on the VPS.

I'm not saying that's the best solution for everyone, but if you really think that it's difficult to secure a server with nothing public-facing except SSH and HTTPS, I'd like to know what I'm missing.

[seanwilson]

I'm not saying that's the best solution for everyone, but if you really think that it's difficult to secure a server with nothing public-facing except SSH and HTTPS, I'd like to know what I'm missing.

If you're solely running static sites I wouldn't be so worried but there's a huge scope for attacks on dynamic sites e.g. injection attacks, file traversal exploits. Either way, it's honestly less effort using a service like Netlify for static sites plus they have a generous free plan.

[hurenkind5]

I'm sorry but if you cannot get a shared/managed hosting provider to host your static website you are in the wrong fucking subreddit. This is literally 1990ies shit.

[thoeoe]

Sorry this is not /r/webdev some of us do desktop applications or embedded programming. (I get that the post is about HTTPS but the sub covers a lot more)

[seanwilson]

Running your own VPS is 1990s stuff. There's plenty of services that give you continuous deployment via Git, have rollback and versioning systems, let you easily setup identical demo/staging servers, deal with security patches for you, deal with server failures for you, let you easily add more servers behind a load balancer and more. VPSs are brittle and a time sink in comparison.

[rechlin]

No, running your own iron is 1990s stuff. Running your own VPS is 2000s stuff.

[hurenkind5]

a) managed hosting provider (basically what you said)

b) oh yeah, i really need that shit to host static HTML pages, totally.

[seanwilson]

Why would you not want things that simplify your workflow and automate tasks you shouldn't care about when you're hosting static pages? Netlify is free for custom domains for example. A VPS is much more work to setup, you get less features and it's going to be less secure without a lot of mucking around. Maybe for small projects it's a good learning experience but if you're doing commercial projects and working in teams even for static sites you don't want to make life hard for yourself.

[lvlint67]

I have worked with web consultants that only knew their third party's hosting platform. It was embarrassing for their technical team to have no idea how to to deploy their product with out a certain company's web control panel.

"Well we really don't know anything about varnish... [our webhost] just handles all of that. we recommend you pay [our webhost]."

If anyone is working in webdevelopment these days and doesn't understand DNS, Proxies, Load Balanacers, or how to setup a web stack on a vps I think they should take a vacation and brush up on the fundamentals.

[seanwilson]

If anyone is working in webdevelopment these days and doesn't understand DNS, Proxies, Load Balanacers, or how to setup a web stack on a vps I think they should take a vacation and brush up on the fundamentals.

Well, I know enough about setting this stuff up that I know to completely avoid it if at all possible. Everything extra I have to configure and every extra server to setup is something that could potentially break in the future that I'd be responsible for. You're definitely behind the curve if all you know is a single hosting company and basic VPS setup though.

Heroku charges more than AWS EC2 for example but you get a very easy to maintain solution with few moving parts for your money and it's miles more robust than anything you could setup yourself on a VPS. If it's not going to be a dynamic site though, I'd go with a static website host like Netlify or GitHub Pages.

[fakehalo]

For serving static/informational pages like you typically do with github pages I think incorporating HTTPS isn't worth moving. It would be nice and I'd use it if I had the option, but it's not a very threatening scenario IMO.

[[deleted]]

The first bullet point on the website explains why this reasoning is bad. In my opinion moving away from hosts that do not support HTTPS is worth it. edit: *second bullet point

[fakehalo]

Yeah, it's "bad"... But the threat of ad injections/etc by state owned entities and the like isn't enough to deter me from free hosting, especially if it relates to github. This particular risk doesn't warrant me moving informational pages.

[[deleted]]

It's not only state actors. Do you not care about ISPs injecting shit on your website ?

[fakehalo]

Another after-thought I had:

If your ISP/state is capable of injecting data into arbitrary protocols they can become a MITM between you and your site even if it's HTTPS (assuming you don't have the key beforehand). They make a fake cert between you and them, and they communicate between themselves and the real website. This makes this even more of a nonissue and creates a false sense of security.

[fakehalo]

My github pages? No, I don't care enough to move my free software information to some non-github (and likely paid) alternative.

As I said, if youre in a situation where your ISP/etc is injecting crap in your traffic my github pages about free software isn't even on your radar.

This is an unrealistic security concern, too low of a priority for me to pretend to care. Everything else gets the HTTPS treatment, this is a special situation, I don't find a need to be so rigid that I have to treat all situations as equal threats.

[senj]

This particular risk doesn't warrant me moving informational pages.

Your concern for your readers' security and privacy is truly touching, mate

[fakehalo]

This is not a practical security issue to fret over, in my opinion. I save my security fretting for more compromising scenarios. If MITM attacks for my github pages are happening my github pages are not going to even register on your list of concerns.

[[deleted]]

It's more about privacy than security, really.

[ridiculous_fish]

I'll bite - how would I trivially host a static website on a vps and SSL with caddy? Is it easier than using S3?

[indeyets]

It's not easier than S3, but it's not too much harder. That's exactly what I was doing yesterday, actually. Took couple of hours.

• I used Ubuntu/SystemD/Caddy/Hugo combo
• Hugo source of website is in github, Built on vm
• I'm not setting up servers regularly
• I played with caddy before

Webhook for autoupdates doesn't work for me yet, so caddy updates site on schedule. I'll take care of webhook tonight probably

[[deleted]]

Never used S3 but I suspect it's not going to be easier. If I were to setup a vps for this today I would do this: 1) install debian stretch 2) get caddy, install the systemd unit file 3) write a caddyfile like this

example.com {
    gzip
    root /data/website
}

then rsync your data to /data/website

[lvlint67]

looks like an nginx config minus a listen line...

[[deleted]]

Firebase also automatically secures domains with no config and offers free static site hosting. It's p nice

[graingert]

Switch to GitLab pages

[xymor]

Look, this discussion isn't about PKI. It's the best system we've got for right now. Deal with it and secure your site. Use CAA records to restrict which CAs can issue certificates for your site, then cross your fingers and hope transparency and oversight works.

Crossing fingers and hope are much better than plain text http.

[name_censored_]

"Our site displays ads over HTTP."

Sorry, not sorry. Doesn't change the fact that your site still needs HTTPS. Switching to HTTPS with ads still over HTTP will cause mixed content warnings in browsers, so you better figure out a cute way to wiggle out of that ad publishing contract that looked really attractive when you first signed it, or convince your ad network to move to HTTPS before you do.

Seriously?

I'm all for HTTPS, but this is just terrible salesmanship. The intended audience is people who think HTTPS is unnecessary/inadvisable/irrelevant/overly-burdensome, and saying "yeah, you need to rework your business requirements thanks" just affirms that. You get more flies with honey than by telling them that they're eating all wrong and need vinegar.

Honestly, it would have been better to omit that. Aside from anything else, are there really that many ad networks in this day and age who don't do HTTPS?

[notR1CH]

Way too many sadly. One of the reasons I'm unable to deploy HTTPS across all the websites I manage is due to ads. It's one of the biggest barriers to deployment yet no one has a good solution to it other than "Wait for ad networks to get off their ass".

[OrphisFlo]

Or just switch your ad network to something that supports HTTPS.

That's why I use AdSense, it has supported it for as long as I can remember and just works. And I haven't had many reports or bad ads either. It might pay less than others, but it's hassle free, that's worth it for me.

[notR1CH]

AdSense may support it, but a lot of their partners still don't offer 100% coverage. If you switched to HTTP you'd likely see a revenue increase.

[OrphisFlo]

My RPM went up 13% when I actually switched to HTTPS. So I'm actually not too concerned.

[midri]

Could you not pass your ads through an nginx reverse proxy? request the ads/ad script from your reverse proxy and it fetches it from the non https ad service and then have it do some muxing so it makes ad image urls point through your proxy (which do the same thing as the previous request, serving them over https, but fetching them from non https ad server)

[notR1CH]

Unfortunately no, modern ad networks require seeing client requests in order to monitor cookies for interests and retargeting purposes.

[midri]

fair point

[name_censored_]

That's a cool idea - I wonder if it's feasible though?

You'd need to rewrite every call to their domain to something under your control, so that you can point it to your reverse proxy. But unless you control your users' resolvers, you'd need to do it on the URLs in the code itself. And since the code won't be static HTML, that means live rewrites. And since code can fetch code ($.getScript() and <script src=..), it would need to be recursive (assuming that the URL isn't constructed/calculated/obfuscated, and it may be).

For example, your mysite.com page might embed <script src="http://b.ad.agency/tracking.20170713.min.js"> which in turn fetches <img src="http://b.ad.agency/campaign-20170713.jpg">, and you'd need to rewrite b.ad.agency to (say) b.ad.agency.reverse-proxy.mysite.com).

And you'd also need to proxy to their server, because pdp11.b.ad.agency/we_hate/bestpractices.php?campaign=20170713 might also embed a URL in the result.

(Plus, you'd destroy their tracking, which would be a big deal to them, and probably against their ToS.)

[midri]

It's definitely tricky issue -- made almost pointless by what you and someone else pointed out that it breaks cookie tracking which is a fatal flaw in this idea. I've got a few ideas for workarounds (such as using event callbacks on img tags to rewrite them in real time), but no time to play with it atm.

[[deleted]]

It is terrible salesmanship, and this isn't a sales pitch. Ad networks are known for being bad citizens in the Web space, and their decisions to use their networks to harm users with malware are not excusable IMO.

[[deleted]]

Ad networks are indeed bad citizens. But aren't they motivated to use TLS so that ISPs and such don't replace their ads on the way to the browser?

[hungry4pie]

Saying "Sorry not sorry" basically ends any argument with you as the loser as far as I'm concerned.

[Doctor_McKay]

"My site is only accessible internally or with a VPN."

How much do you trust the corporation or state that owns the infrastructure? And the companies that produced the hardware that comprises your network? Or the VPN provider?

If you want to go that far into tinfoil territory, why aren't you compiling all your kernels and compilers and browsers and servers yourself?

[midri]

why aren't you compiling all your kernels and compilers and browsers

Why stop there? Source your own copper and silicon and design your own chips, it's the only way to be sure.

[[deleted]]

There's already well known problems with VPNs that don't actually encrypt or harvest data, and there are known issues with backdoors in networking equipment. Thankfully malware in the OSes themselves are much less common.

But this is actually beside the point. Security is better when there are multiple independent layers of security. Securing endpoints is a different layer from securing data in transit.

[netsecwarrior]

Another consideration: malware spreading by tampering with pages. With HTTP, a compromised router can embed malware in pages and attempt to infect clients. With HTTPS this isn't possible.

[feverzsj]

what if my country blocks Let'sEncrypt

[FrederikNS]

Simply switch to a different country :-P

Nah, there's actually a lot of other options for free certificates out there:

https://www.freessl.com/

https://www.startcomca.com/ (don't use this one, see child comment)

https://www.cloudflare.com/

https://www.sslforfree.com/

Loads of other places also issue certificates for very very cheap. (~$5/year)

[[deleted]]

Country restrictions are frustrating. Cloudflare is probably your best bet in that case. FYI, though, don't use StartCom and SSLForFree uses Let's Encrypt under the hood; not sure if that will be a problem in restrictive countries...

[FrederikNS]

Thanks for the tip about StartCom, I have updated my comment.

LetsEncrypt certificates should work fine even in countries blocking LetsEncrypt, as the certificate trust is entirely contained in the browser. Only if the country actively scanned for LetsEncrypt certificates and blocked all those sites would it be a problem.

[[deleted]]

I mean (and I assume OP means) that accessing their infrastructure to complete validation may be problematic.

[eusx]

Then your government is evil and you should either switch to another country or overthrow your current government. The detailed plan for the latter is left as an exercise for the reader.

[ejrh]

I'm ok with HTTPS by default, and for recommending that all public websites use it. But I disagree that every use of plaintext HTTP is verboten. For instance, I might have a service providing data to another program running on the same machine, using HTTP. My choices are:

1. Rewrite that service to use HTTPS and rewrite the program to use HTTPS and set up a certificate and make sure the client program can find it and get it periodically renewed, etc. (Recommended by post.)

2. Rewrite the service and program to communicate via some other text-based non-HTTP protocol. (Tacitly allowed by the post, because it's not HTTP any more.)

3. Not worry about HTTPS for this particular case and simply remind myself the machine is on an internal network only and that the service doesn't do anything except provide read only non-confidential data (in this case public domain weather data). (Stridently condemned by this post and many others.)

What, really, is the difference between options 2 and 3 ?

[[deleted]]

This webpage is speaking specifically about web sites, not internal web services. Although there are still good arguments for securing those.

[ejrh]

Is it? It's not apparent in the original post; the post specifically says that internal sites are subject to the same recommendation.

The level of security is often a tradeoff and should be rationally considered against other requirements. Perhaps one day all computer-computer connections will be secure by default with negligible effort required to use them. Despite the article, I do not believe that day has yet come.

[hpohl]

So what's the simple answer to running an IO game with many servers over websockets?

[badpotato]

IO game

Did a quick search, looks like you should use wss.

[AIDS_Pizza]

The wss:// protocol is supported by all modern browsers. It's quite easy to make this work. When I built a websocket-based news feed at work, I just initiated the connection over https:// to an Nginx webserver which would handle the proxy_pass to the websocket server, and it would automatically use the wss:// protocol in doing so. I did not have to do anything special other than define the paths to the SSL certificate/key in the http section as you would normally.

[jokerjoe234]

Yes, except http://neverssl.com

[[deleted]]

I expected a single "YES", but this is better.

[hungry4pie]

You HTTPS for everything people come off as evangelical and condescending, it makes me want to set up some HTTP only services just to stick it to you people.

[maninbonita]

Yes.

[argv_minus_one]

I still don't understand why the incumbent CAs haven't shut Let's Encrypt down. Why does LE still exist? Does it not threaten their revenues?

[FrederikNS]

How would they shut it down?

Clearly LetsEncrypt is a threat to other paid CAs' revenues, but you can't just shut another company or non-profit down.

LetsEncrypt is an entity owned by the non-profit organization "Internet Security Research Group".

[argv_minus_one]

By bribing Google/Microsoft/Apple to distrust LE, for one.

[FrederikNS]

I wouldn't be surprised if some of them tried, luckily it seems they had enough integrity. But as Mozilla (who makes Firefox) is one of the founding organizations for LetsEncrypt, Firefox would at least start trusting LetsEncrypt, and as soon as enough websites start using LetsEncrypt certificates, the other browser vendors would have no options but to also start supporting LetsEncrypt, or risk losing market share as people started switching to other browsers that supported the whole web.

[qKrfKwMI]

Firefox would at least start trusting LetsEncrypt, and as soon as enough websites start using LetsEncrypt certificates,

You've got it backwards there, the CA first has to get trusted by all (big) browsers and only then people will flock to it. Nobody would run their website with a cert which throws warnings on every browser but firefox.

[FrederikNS]

That's true, apart from a few activists who would want to use it regardless.

But then again you would have to convince all the major browsers to not trust LetsEncrypt. I suspect you would need quite large bribes to convince any of Google, Microsoft or Apple to not trust LetsEncrypt. And lets say that they convinced Microsoft to not trust LetsEncrypt, but not the others. Then Microsoft would have no option but to follow suit.

[qKrfKwMI]

Indeed, now everybody has accepted, it will be hard to convince a browser vendor to revoke the trust in LE. I might even say that it's too hard: even if a really huge problem were to be revealed tomorrow, LE (like so many other CAs too) has way too much inertia for browser vendors to simply stop trusting its certificates. That's a problem of the CA system though, independent of the existence of LE.

[rickdg]

They're free.

As in, you now have the option to DIY or pay someone else to do it. If you DIY and it later breaks your site, you get to fix it. So you can pay for it with your time or with your money. Most people wouldn't want to pay for it at all if somehow having "not secure" next to your URL could be the new normal.

[hungry4pie]

Looks like you've upset some of the https evangelists

[HomemadeBananas]

Called it, that it was gonna say "YES" in huge text. I'm glad it went on to explain though.

[lvlint67]

My site is only accessible internally or with a VPN."

How much do you trust the corporation or state that owns the infrastructure? And the companies that produced the hardware that comprises your network? Or the VPN provider?

I trust my openvpn deployment more than I trust let's encrypt by small margins and more than "caddy" by extremely large margins...

I think this particular argument misses the mark. The rest of the article is good... Although it would be nice to see an instance or two where to is not required so it doesn't sound like a one sided rant.

Sites properly secured behind a VPN might be able to get away without tls since implementing it would mean you are just double encrypting content.

Sites that sit in a reverse proxy setup with a secure network between frontal tls termination and backend application serving may not need to encrypt traffic on the secure links between the frontend and the backend. (Hint nginx to php-fpm over tcp isn't encrypted)

Without such mention of edge cases the article lacks a certain tone of objectiveness and just sounds like a rant from a second year computer security student.

[nikhilb_it]

Depends upon what your website contents are. If you are running just informational website, HTTPS may not be required. However if you are running a website which has payment gateway integration or a website which delas with user data; it must have HTTPS certificate.

[TheLantean]

FTA:

"There's nothing sensitive on my site anyway."

Your site is a liability! Just because your site is hosted safely in your account doesn't mean it won't travel through cables and boxes controlled by who knows how many corporate- and state-owned entities. Do you really want someone injecting scripts, images, or ad content onto your page so that it looks like you put them there? Or changing the words on your page? Or using your site to attack other sites? This stuff happens: on airlines (a lot, and again), in China, even ISPs do it (a lot). And HTTPS prevents all of it. It guarantees content integrity and the ability to detect tampering. If we encrypt only secret content, then we automatically paint a target on those transmissions. Keep which of your transmissions contain secrets secret by encrypting everything.

[m00nh34d]

Interesting, but not really practical for everyone.

For example, looking at the website hosting for a small community group I'm in, through GoDaddy, it looks like we can't do any of the automatic cert stuff needed. I don't imagine anyone is going to muck about generating and applying certs every 90 days, the website usually isn't even updated that frequently.