Required maintenance for a simple, static https site: configure let’s encrypt and keep the cron job running.
Big difference? Not for some, but it sure is something that offers very little value for very many site owners. Even the top 100 sites are only at 80% https by default, and they do it for a living!
Because it's not meant to offer value for a site owner, it's meant to offer value to the user.
When I type a password on your website, I'm the one that has the most to lose there. When I type my credit card or other personal information into a site, I'm the one that will need to spend time and money getting control of my information if it was stolen.
When I am browsing the web and ads are being injected into the HTTP request, or my ISP is dragnet datamining, or a compromised router is injecting malware into every page, I'm the one that loses, not you.
The argument that an insecure website is easier to maintain than a secure website is like saying "a car without airbags is easier to work on". The extreme vast majority don't care about how easy it is to maintain the site, they care about their privacy and security.
And your counterpoint is needing to download and run some open-source software once a month (or automate the process and never touch it again). A few years ago that would have been a much larger list, but developers were listening to the complaints, and realized that the only way to a fully secure web was to make this process easier, so they did!
It's easier than ever to enable HTTPS on every website, and in the vast majority of cases it's a net improvement for users.
And privacy of information going from your browser to the internet is only half of the equation. What about privacy about what you are viewing?
I don't want every single router between my computer and the server knowing the full contents of the pages I'm choosing to view, or building advertising profiles on my habits, or even knowing what device type, browser, OS, and more I'm using.
So don’t use a shitty ISP that tries to MITM you.
Problem solved. How is that even controversial?
Rather than the hospital supplying any kind of proper authentication, they MITM the first connection to their WiFi, and logged your IP address as your user. They also required you refresh that connection every half hour or so.
There are a lot of people doing things in really bad ways.
We can't fix all of them, and often we don't have a choice about interacting with them.
Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this?
That way if someone MITM'd you, you would see that the cert changed, right?
But I guess if the path you use to the website is always the same, then if they MITM'd you the first time you accessed it, you wouldn't be able to tell?
Hmm, I guess that probably isn't enough then.
Is there really no good way to serve public information from a website that doesn't require periodically updating one's cert, and without risking MITM'ers changing the content?
I guess if the client already has the hash of the content, but that isn't very convenient.
Huh.
I guess example.com needs https then?
They don't use HSTS to force it, because example.com isn't meant to anything but an example.
Yes, but browsers make that MUCH more scary than surfing insecure (not https) sites.
I can publish my personal CA certificate and ask you to trust it. This is hardly different than how I prove myself to Lets Encrypt.
These days Let's Encrypt uses a "multiple view" approach in which more than one physical location in the world hosts Let's Encrypt systems (although only their US West Coast location contains the actual CA) and so they can check that things appear the same from more than one angle, you can't just take over the ISP they're getting service from in California and leverage that to get anything you want. If the views don't agree (e.g. you pass a Let's Encrypt validation from Paris but not from San Francisco) then your application is denied automatically.
Now, the next layer above is also interesting. Who checks Let's Encrypt and other public CAs are doing their job? Fortunately Mozilla are on the case again, all major Trust stores say they enforce the Baseline Requirements which explain how a CA should do its job, but all except one make decisions entirely in private. Or maybe they just bin all the complaints if the CA pays them a bribe? Who knows. Mozilla acts openly in public, you can (and indeed your insight might be valuable, so please do) help oversee the Web PKI in their m.d.s.policy group.
Problem is that browser warnings are sometimes false. Self signed certificates are not unsecure, the underlying encryption is still the same. The "unsecure" only applies to the CA, but that is not clear in the warning.
Browser warnings aren't false, you're reading of them is false. Read around on badssl.com [0]. The self-signed warnings in chrome say:
>Attackers might be trying to steal your information from self-signed.badssl.com (for example, passwords, messages, or credit cards).
And when you click advanced chrome says:
>This server could not prove that it is self-signed.badssl.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
It says nothing about the encryption being bad, I don't know where you got that from. What it does say is that Chrome has no way to validate that the site you are going to is actually the site in the address bar. Encryption is pointless if anyone and everyone knows the password (oversimplified, but you get the point). Encryption without Authentication is as secure as normal HTTP.
No it is not wrong, even your confusingly worded sentence there is still fully correct.
Security (or encryption, or any other synonym you can come up with here) is made up of 3 (well technically 4) parts:
* confidentiality
* integrity
* authenticity
* (and technically non-repudiation, but that doesn't really apply here)
self-signed HTTPS certificates only provides 2 of the 3 (confidentiality and integrity) and it's that last one that is most important (authenticity), because without it you don't know who you are talking to. It could be your website, or it could be some asshole down the street pretending to be your website, you have literally no idea.
You say it's misleading, but it is you that is misreading and misunderstanding the concepts. Encryption without authentication is like encryption without a password. Utterly pointless.
Just like my analogy, AES encryption with a password of nothing is "unsecure", and no matter how much you try to argue that it's still perfectly secure, you are wrong..
Just like this, the AES is pointless when ANYONE can set the password (or in more correct terms, when anyone can create one with the user in a DHKE). If you can't tell that the server you are talking to is actually the server you meant, then AES does fuckall, because the man-in-the-middle is the one that is setting the password!
You are doing the equivalent of telling me how secure your new house door lock is, while wiring it up to always unlock when someone rings the doorbell... All the security in the world won't help you when you give everyone a way to bypass it instantly.
Luckily browsers will show you the warning saying that page is insecure, and give you the option of going there anyway after you have validated that the cert is the same.
"keep a cron job running" sounds like it you're running the cron job by hand.
>Even the top 100 sites are only at 80% https by default, and they do it for a living!
That's entirely separate from your "simple, static site" example and yes, rolling any sort of large change out to a big site is a big deal, and if there isn't business motivation to do it it likely wont happen. Google is providing everyone a business motivation by threatening to point out to users that insecure sites are insecure.
Cron jobs fail sometimes. You have to monitor them, investigate why they failed, fix the issue, and rerun them.
Web servers fail, too, but with shared hosting, it's mostly not your problem. And shared hosting providers are still trying to charge an arm and a leg to manage SSL certs for you (because it's a nice high-margin business for them).
2. Let's Encrypt will send you an email if your certificate is going to expire in a month. This will normally never happen, since it is continuously renewed.
You now have to configure e-mail on your small server to actually work (and not get immediately eaten by spam filters of your personal e-mail provider).
Eg tools like cPanel have built in support for it now.
Really?
But I don't think most site owners should be doing even that much. They should just pay for static hosting, which is cheap and ensures somebody else will keep the server, os, and cert all safe.
ubuntu + nginx worked fine for years without much maintenance, but I've spent so much time reconfiguring things when something breaks (and it is really clear when something a renewal fails... thanks HSTS).
Things that used to be simple, like putting setting up a subdomain (need to get a new cert and reconfigure the cron job now) or pointing at a websocket (can't point directly at node since that's not secure, needs to pass through nginx now) consistently take hours to do now.
I mostly do data analysis and front end work; mucking around in nginx config files is something I would have been happy never experiencing. It sucks that it's harder to host your own website now.
It's really hard to imagine it getting much easier.
Advantages are that it is free and zero maintenance, however nation or network providers can intercept between cloudflare POP and my server. I'm ok with that for my situation.
Cloudflare may have made it more common for the most basic kind of site (with their easy setup and free tier) but at the same time most of those sites probably didn’t use https anyway.
The reasons this has been done are performance (specialized hardware/separation of concerns) load balancers/firewalls needing to decrypt to route/enforce policy (that doesn’t need to imply termination but it often goes hand-in-hand) and protecting keys from your app server (think of it as like an HSM - if your app server gets compromised you probably don’t want the TLS private key to be leaked. Again you could reencrypt with a different key but often this hadn’t been done.)
The threats for last mile network fuckery (e.g. consumer ISP) are quite different then on the backend. Google has to worry about nation states messing with their networks and so they’ve had to reengineer end-to-end encryption within their network. As an end-user you just sort of need to accept that this isn’t within your ability to control or know.
Even still, the difference between this and e2e encryption isn’t something an end user is really equipped to evaluate IMO. The threat model is practically different vs e2e no-encryption.
Cloudflare also supports reencryption over the net which is useful if your hosting provider supports HTTPS but not via a custom domain (e.g. Google clouds GCS (S3))
With services like Cloudflare, you can terminate TLS at CF, and then proxy over the public internet to the server that actually serves the page, which I think defeats a lot of the purpose of TLS, and I can never know ahead of time when I request a page of HTTPS if this will in fact be what's happening.
That said, using certbot made it so painless I just started doing it at some point for everything I run and I only once had a small hiccup configuring a renewal-hook.
This argument from cost doesn't seem like a compelling one to me. It's not money being thrown away, it's delivering real added security.
Then not just one but two huge tower blocks in London burned down. So how about that, suddenly maybe tower blocks _did_ need sprinklers after all. Shame about all the dead people.
It's better to use a content-hosting service, and as a bonus you don't have to keep cron jobs running in order to get TLS.