4 ms·

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

by namibj 7y 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.

Sukera 7y ago
Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/
- deleted 7y ago
  [deleted]
- namibj 7y ago
  Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.
  - dependenttypes 7y ago
    This should happen only during the handshake though.
- kevingadd 7y ago
  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.
  - acdha 7y ago
    How long ago was this — and how fast was your network? On hardware less than a decade old you shouldn’t be seeing that unless you’re talking about 10+Gb networking.
    - kevingadd 7y ago
      A year ago in my development VMs, it was the difference between like 40MB/s throughput and 200+
NohatCoder 7y ago
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.
- namibj 7y ago
  I speak of a L7 DDoS. Assume the worst way to attack without being clearly obvious: handshake CPU grinding.
Ayesh 7y ago
This is an argument I hear often, but I have yet to see an effective L7 DoS with the TLS handshake being the bottleneck. It's almost always the application code that gives up, rather than the CPU spikes due to TLS. I have a 1 vCPU 2GB server that terminates TLS with dual Prime256v1/curve25519 + RSA 2048 setup with a 10 minute keepalive time, running AES 128, 256 (CPU has AES-NI), and CHACHA20-POLY1305 comfortably handling several millions of requests a day and CPU load hovering 10-20%. The amount of ECC handshakes are surprisingly high, and CHACHA works wonders too with user agents today. Given the threats from passive attacks today, this is a cost that must be paid. It just looks quite affordable with modern protocols.
- oarsinsync 7y ago
  > comfortably handling several millions of requests a day and CPU load hovering 10-20% Parent suggested that at 172 million requests per day (2000 rps), there would be trouble. Assuming "several million" is <= 17 million (or even up to 34 million, given the 10-20% range stated), then your stats would tend to agree.
shakna 7y ago
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.
- SlowRobotAhead 7y ago
  It’s not exactly apples to apples... but my 64Mhz embedded processor is doing way more than 10,000 chacha20-poly1305 encodes of 64 bytes with another 64 bytes of additional data for the AEAD per second. Granted, it has some hardware crypto functions. I am still skeptical TLS handshake on site visit is actually bogging down anyone’s computer.
  - namibj 7y ago
    The stream cryptography is not the issue here. Neither is "TLS handshake on site visit". The issue is that you have to spend the handshake cost before you can look into the request at all.
ATsch 7y ago
If this is true, how do you explain the lack of any notable L7 TLS DoS attacks?
- namibj 7y ago
  People throwing up CDNs and dumb bandwith blasting often being easier?
driverdan 7y ago
Assuming this is true 2000rps per CPU core seems pretty reasonable. That would only be a bottleneck when serving static files. Only the most basic apps are going to be able to serve that much traffic per core.

by namibj 7y ago

Sukera 7y ago

Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/

deleted 7y ago
[deleted]
namibj 7y ago
Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.
- dependenttypes 7y ago
  This should happen only during the handshake though.
kevingadd 7y ago
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.
- acdha 7y ago
  How long ago was this — and how fast was your network? On hardware less than a decade old you shouldn’t be seeing that unless you’re talking about 10+Gb networking.
  - kevingadd 7y ago
    A year ago in my development VMs, it was the difference between like 40MB/s throughput and 200+

NohatCoder 7y ago

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.

namibj 7y ago
I speak of a L7 DDoS. Assume the worst way to attack without being clearly obvious: handshake CPU grinding.

Ayesh 7y ago

This is an argument I hear often, but I have yet to see an effective L7 DoS with the TLS handshake being the bottleneck. It's almost always the application code that gives up, rather than the CPU spikes due to TLS. I have a 1 vCPU 2GB server that terminates TLS with dual Prime256v1/curve25519 + RSA 2048 setup with a 10 minute keepalive time, running AES 128, 256 (CPU has AES-NI), and CHACHA20-POLY1305 comfortably handling several millions of requests a day and CPU load hovering 10-20%. The amount of ECC handshakes are surprisingly high, and CHACHA works wonders too with user agents today. Given the threats from passive attacks today, this is a cost that must be paid. It just looks quite affordable with modern protocols.

oarsinsync 7y ago
> comfortably handling several millions of requests a day and CPU load hovering 10-20% Parent suggested that at 172 million requests per day (2000 rps), there would be trouble. Assuming "several million" is <= 17 million (or even up to 34 million, given the 10-20% range stated), then your stats would tend to agree.

shakna 7y ago

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.

SlowRobotAhead 7y ago
It’s not exactly apples to apples... but my 64Mhz embedded processor is doing way more than 10,000 chacha20-poly1305 encodes of 64 bytes with another 64 bytes of additional data for the AEAD per second. Granted, it has some hardware crypto functions. I am still skeptical TLS handshake on site visit is actually bogging down anyone’s computer.
- namibj 7y ago
  The stream cryptography is not the issue here. Neither is "TLS handshake on site visit". The issue is that you have to spend the handshake cost before you can look into the request at all.

ATsch 7y ago

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

namibj 7y ago
People throwing up CDNs and dumb bandwith blasting often being easier?

driverdan 7y ago

Assuming this is true 2000rps per CPU core seems pretty reasonable. That would only be a bottleneck when serving static files. Only the most basic apps are going to be able to serve that much traffic per core.