41–50 of 345 posts
There is one "good" reason against https: handshakes take enormous amounts of CPU, relatively speaking. It's quite easy tp DoS server by skipping the expensive part on your end. You can load a core with 10~30Mbit@2k rps if your not even optimized. Whereas the same server could tank 40k rps HTTP requests.
Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/
Earlier quoted context omitted.
I'm fine with people who think it's too hard... What i cannot stand is people who can do it, but refuse to out of laziness. Or because they want their content to be insecure on purpose. This applies mostly to big orgs, so indie devs can have some leeway if it's too hard to implement.
> i cannot stand is people who can do it, but refuse to out of laziness (Raises guilty hand) I run a couple of sites on my hosted server that are still http. They both sit behind a varnish setup and to be honest I just have not found the time to get it done. Usually when I mess with my configurations I lose a week to troubleshooting stupid stuff and I just can't bring myself to do it.
Earlier quoted context omitted.
It is simple for a one-server website. When you're on Alexa 1M, you certainly have a load balancer, multiple servers for redundancy, etc. It makes things not straightforward, and you certainly don't want to use the default certbot which overwrites your config.
I am on alexa 1m (50k even). I do not have a load balancer, I do not have multiple servers for redundancy. This isn't even a static site, most of our page views are the wiki, the server running all of this has 8 cores and 4 are constantly maxxed out by a non-website related process. Most websites now and days are over engineered.
Earlier quoted context omitted.
Instructions are here: https://certbot.eff.org/ I don't know how it could possibly be any simpler.
It is simple for a one-server website. When you're on Alexa 1M, you certainly have a load balancer, multiple servers for redundancy, etc. It makes things not straightforward, and you certainly don't want to use the default certbot which overwrites your config.
Earlier quoted context omitted.
Instructions are here: https://certbot.eff.org/ I don't know how it could possibly be any simpler.
It is simple for a one-server website. When you're on Alexa 1M, you certainly have a load balancer, multiple servers for redundancy, etc. It makes things not straightforward, and you certainly don't want to use the default certbot which overwrites your config.
Some websites adamantly insist they did not need HTTPS because they are purely static. https://www.troyhunt.com/heres-why-your-static-website-needs... The same website to my surprise has an article on why this is faulty reasoning.
If I set up a purely static HTTP-only site in 1998, it would still work with today's browsers, more than 20 years later.
If I set up a purely static HTTPS-only site in 1998, and didn't follow the upgrade treadmill, it would have stopped working for modern browsers some time ago.
There is one "good" reason against https: handshakes take enormous amounts of CPU, relatively speaking. It's quite easy tp DoS server by skipping the expensive part on your end. You can load a core with 10~30Mbit@2k rps if your not even optimized. Whereas the same server could tank 40k rps HTTP requests.
There is one "good" reason against https: handshakes take enormous amounts of CPU, relatively speaking. It's quite easy tp DoS server by skipping the expensive part on your end. You can load a core with 10~30Mbit@2k rps if your not even optimized. Whereas the same server could tank 40k rps HTTP requests.
Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/
openssl speed ecdh
gatling -V -n -p 80 -u nobody
Feel free to try.
There is one "good" reason against https: handshakes take enormous amounts of CPU, relatively speaking. It's quite easy tp DoS server by skipping the expensive part on your end. You can load a core with 10~30Mbit@2k rps if your not even optimized. Whereas the same server could tank 40k rps HTTP requests.
Depends on the stack used. If you have persistent connections you'll incur far fewer handshakes than requests. If you use an elliptic curve scheme key exchange costs are negligible. But sure, if you do one 4096 bit RSA exchange for every request it will be costly.
Assume the worst way to attack without being clearly obvious: handshake CPU grinding.
Because it's always pain in the ass to set it up and then renew?
- If you are hosting a simple static page or blog, your hosting provider probably has Let's Encrypt plugin.
- If you have your own VPS, Caddy has you covered with file serving, fastcgi support for PHP, and proxying to (g)unicorn/nodejs/Go/.NET, and has HTTPS enabled by default.
- If you have more advanced setup (e.g. containers), traefik supports HTTPS with just a few lines of configuration.
- If you are big enough to afford cloud, it takes a few lines of Terraform code to provision certificate for load balancers (speaking for AWS, and assuming others have similar solutions).
For other cases (e.g. lots of traffic with custom haproxy/nginx/etc. setup), you are probably smart enough to find out how to enable Let's Encrypt support.