Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

61–70 of 345 posts

Re: Still Why No HTTPS?

#61
post #19
post #10

Earlier quoted context omitted.

There are some other confusing ones as well. nature.com is marked as Chinese, as are nginx.org and ntp.org. example.com is Indian in the list as is the now defunct dmoz.org. I don't understand the methodology behind the country assignments at all…

Weirdly nature.com seems to actually redirect to https, as does zara.com, lenovo.com, genuis.com, and senate.gov. Is this list stale, or did no one spot-check this?

It takes multiple redirects to reach https for several of those. It may just be looking at the first hop - which makes a certain sort of sense.

Re: Still Why No HTTPS?

#62
post #27

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.

The only place I've had to care about this was on an embedded hardware server. Even then, if the handshakes were too much, it'd just drop the connections and continue to serve those it could. It wasn't enough to knock the whole thing offline.

If a 16bit 200Mhz microprocessor can handle a few thousand connections/second, then a modern processor should definitely be able to stay upright fairly easily.

Re: Still Why No HTTPS?

#63

Because it's always pain in the ass to set it up and then renew?

Set up once and then a cron-task? [0] It doesn't have to be a pain. The tooling around this all exists.

It's very very nearly maintenance free [1].

[0] There's lots of tooling. My current preference is for https://github.com/lukas2511/dehydrated

[1] If something breaks you have to pay attention, otherwise... Not so much.

Re: Still Why No HTTPS?

#64
post #33
post #27

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/

In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day.

For the average case it probably doesn't matter, and you can optimize it, but I think it is totally understandable that the average novice could end up with bad https performance if only because the defaults are bad or they made a mistake. If hardware assist for the handshake and/or transfer crypto is shut off (or unavailable, on lower-spec CPUs) your perf is going to tank real hard.

I ended up using ssh configured to use the weakest (fastest) crypto possible, because disabling crypto entirely was no longer an option. I controlled the entire network end to end so no real risk there - but obviously a dangerous tool to provide for insecure links.

Also worth keeping in mind that there are production scenarios now where people are pushing 1gb+ of data to all their servers on every deploy - iirc among others when Facebook compiles their entire site the executable is something like a gigabyte that needs to be pushed to thousands of frontends. If you're doing that over encrypted ssh you're wasting cycles which means wasting power and you're wasting that power on thousands of machines at once. Same would apply if the nodes pull the new executable down over HTTPS.

Re: Still Why No HTTPS?

#65
post #61
post #19

Earlier quoted context omitted.

Weirdly nature.com seems to actually redirect to https, as does zara.com, lenovo.com, genuis.com, and senate.gov. Is this list stale, or did no one spot-check this?

It takes multiple redirects to reach https for several of those. It may just be looking at the first hop - which makes a certain sort of sense.

Article states they allow multiple 301 or 302 redirects. What is not allowed are JS based redirects. There might also be a limit to the number of redirects followed, but that isn't mentioned in the article.

Re: Still Why No HTTPS?

#66
post #5

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 started using lets-encrypt before it supported Nginx (using standalone mode). I recently tried the Nginx-based mode, and it wrecked my reverse proxy config pretty thoroughly.

Still, the stand-alone mode is pretty dang easy. I've also considered the /.well-known mode but there was some tiny snag.

Re: Still Why No HTTPS?

#67
post #13

Is it still the case that when you think you connect in https to a website, only the segment to cloudflare is encrypted and the segment cloudflare to the web server might not be?

Yes, that's SSL termination. Generally this happens at the CDN, load balancer or proxy (e.g. nginx used as a cache) layer and is pretty common since the fleet of servers handling the request after being routed are in a private network. With CF, the request from CF to the origin is over a public network and it will depend on how the user has configured their CF setup as to whether or not that hand-off is then encrypted. If they are doing SSL termination in CF, then it won't be encrypted from CF to the origin server.

Re: Still Why No HTTPS?

#68
post #13

Is it still the case that when you think you connect in https to a website, only the segment to cloudflare is encrypted and the segment cloudflare to the web server might not be?

Yes, it's called "flexible SSL".

Re: Still Why No HTTPS?

#69
post #27

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.

If this is true, how do you explain the lack of any notable L7 TLS DoS attacks?

Re: Still Why No HTTPS?

#70
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 letsencrypt should allow wildcards to the owner of somedomain.com without dabbling with the DNS.

The way things are now, I don't use ssl for my smaller projects at smallproject123.mydomain.com because I don't want the hassle of yet another cronjob and I sometimes don't want the subdomain to go into a public registry (where all certificates go these days).

Post reply on HN