161–170 of 345 posts
Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.
So like 3-5 minutes of work with Let's Encrypt?
Earlier quoted context omitted.
If we migrate to HTTPS everywhere we can get rid of HTTP for general use and switch to a different UI, where HTTPS websites don't have any special icon but HTTP ones get a warning icon. It's already effectively how password form submissions work in many browsers.
We could already do that — just do away with the padlock icon now . In my browser, anyway, http:// gives a big "non secure" warning.
Because there is only one free certificate provider (lets encrypt) and it does not allow wildcard certificates via server authentification. Having the DNS credentials laying around on the server is not a good idea. So creating wildcard certs via letsencrypt is a huge pain in the ass. If a webmaster has control over somedomain.com I think that is enough to assume he has control over *.somedomain.com. So I think letsen…
AWS certificates are free. Cloudflare will also put SSL in front of your origin for free. So if you’re using AWS you get it for free. Or you can slap CloudFront or Cloudflare in front of your origin. I think the barrier is low enough that I SSL all the things (including my small side projects).
Same here. If you have a domain then you should have a cert, it's not that hard today.
My wife wanted a website that's pictures of our dog as a joke, right now it's a single img tag. The second thing I did after that was getting an HTTPS cert and forcing redirection.
Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.
On the other hand, a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted.
Earlier quoted context omitted.
Even with a static HTTP-only website, there's tons of stuff that you have to update anyway. Hardware gets outdated and needs replacing, at which point you cannot postpone the kernel update anymore because you need the new device drivers, etc. etc. You also don't want to stop updating your HTTP server, CVEs get discovered quite frequently. You can of course draw a line between that churn and the churn of updating your…
> Hardware gets outdated and needs replacing Irrelevant. Low traffic static website. > at which point you cannot postpone the kernel update anymore because you need the new device drivers, etc. etc Irrelevant as I didn't upgrade the hardware >You also don't want to stop updating your HTTP server, CVEs get discovered quite frequently it's a server for serving a single static page from 1998, nothing bad will happen if…
Here's one: the server has a remote code execution vulnerability, which is exploited to gain root permissions, and your server is serving child porn. The cops are knocking on your door.
Granted, this isn't a pro-HTTPS argument, but you do need to keep your stuff updated, even if it is only a static site.
Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.
One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.
Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.
I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind.
The execution is shockingly simple. If you think it's "all that hassle" I guarantee you haven't even tried.
The biggest problem with forcing everything HTTPS is a false sense of security & trust that this gives to none-techie users. Security of the data transfer layer does not mean can or should trust the website you are visiting. Just because a website has a padlock does not mean it is trust worthy and you can hand over your CC details. https://www.amazon.somethiing.other.co/greatDiscount may look great to some!
If we migrate to HTTPS everywhere we can get rid of HTTP for general use and switch to a different UI, where HTTPS websites don't have any special icon but HTTP ones get a warning icon. It's already effectively how password form submissions work in many browsers.
I've seen TV adverts from banks for example (Here in the UK) telling people to look for the padlock! This is not a verifiable method of safety.
I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. I'm guessing people aren't as lucky as I am to be running on newer machines and such. I mean it even edits your nginx files to redirect http to https if you agree. It's not hard.
I currently use a mini CDN (content delivery network) of three different OpenVZ servers in the cloud to host my content, so getting things to work with Let’s Encrypt took about two or three days of writing Bash and Ansible scripts which get the challenge-response from Let’s Encrypt, uploading it to all my cloud nodes, having Let’s Encrypt verify it got a good response, uploading the new cert to all of the cloud nodes, then using Ansible to log in to all the nodes, put the new cert where the web server can see it, then restarting the web server.
Point being, the amount of effort needed to get things to work with Let’s Encrypt varies, and can be non-trivial.
Earlier quoted context omitted.
You can even just set NS records for _acme-challenge subdomain to your own DNS server. And then have your acme client auth against that one. No need for a new domain.
True, though running your own DNS server or paying for another DNS provider may be similar in effort or expense...as compared to a throwaway cheap TLD domain that comes with DNS.