4 ms·

You can track the latest on this issue at: http://meta.stackoverflow.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft

by sams99 14y ago

You can track the latest on this issue at: http://meta.stackoverflow.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft http://meta.stackoverflow.com/questions/69171/why-doesnt-the...

PakG1 14y ago
Via that link, I found this answer. http://meta.stackoverflow.com/a/69177 http://meta.stackoverflow.com/a/69177 Out of curiosity, does anyone know how much traffic I'd have to hit before my "$20 SSL certificate" started being a chokepoint and bottleneck? If I were able to hit stackoverflow levels of traffic, I'm sure I'd be able to figure out a way to afford it (although maybe even they haven't yet), but I'm curious at lower levels of traffic if I should still worry.
- michaelmior 14y ago
  The price of the certificate is irrelevant. The issue is that encryption and decryption eats CPU cycles, so running all traffic via HTTPS on a busy site is going to require significantly more processing power.
  - PakG1 14y ago
    I realize that. I'm asking how much traffic can be handled by a simple single server before it starts dying due to SSL CPU cycles. I do realize now that my question is too simplistic and obviously varies according to the nature of the application, server config, etc. So won't expect any answers for it. :)
    - michaelmior 14y ago
      Definitely a question I can't answer. Although these days SSL is rarely implemented on each individual server. Instead, load balancers handle SSL and traffic is passed unencrypted to the backend servers doing the real work (presumably at this point, you're on a secure network). Many hardware load balancers even have specialized chips for handling SSL.
    - ams6110 14y ago
      Just a guess but if you are running your site on a single server you're going to hit other bottlenecks in things such as your application code or database, your http server, or disk contention, or RAM starvation, before SSL encryption becomes the overriding one.
  - mbrameld 14y ago
    According to Google that's not true. "In order to do this we had to deploy no additional machines and no special hardware. On our production front-end machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." https://www.verisign.com.au/ssl/ssl-information-center/ssl-resources/whitepaper-protect-sidejacking/index.html https://www.verisign.com.au/ssl/ssl-information-center/ssl-r...
EvanAnderson 14y ago
I'm a little disappointed with the answers from Zypher (one of the Stack Exchange sysadmins) and Jeff Atwood. Particularly troublesome is Jeff's statement "If you have a 'man in the middle' then there are deeper problems, like, you're using a compromised network." I'd argue that it's appropriate, from a security architecture perspective, to treat the entire Internet as a "compromised network". Admittedly, my use-case for the Stack Exchange sites (specifically Server Fault) is a little different than most people's and I'm a lot more worried about "theft" of my "identity" there than most people would be. Still, though, I'd like to see the answer revisited in light of mid-2012 technology / costs. I suppose I should go post something over there...

by sams99 14y ago

PakG1 14y ago

Via that link, I found this answer. http://meta.stackoverflow.com/a/69177 http://meta.stackoverflow.com/a/69177 Out of curiosity, does anyone know how much traffic I'd have to hit before my "$20 SSL certificate" started being a chokepoint and bottleneck? If I were able to hit stackoverflow levels of traffic, I'm sure I'd be able to figure out a way to afford it (although maybe even they haven't yet), but I'm curious at lower levels of traffic if I should still worry.

michaelmior 14y ago
The price of the certificate is irrelevant. The issue is that encryption and decryption eats CPU cycles, so running all traffic via HTTPS on a busy site is going to require significantly more processing power.
- PakG1 14y ago
  I realize that. I'm asking how much traffic can be handled by a simple single server before it starts dying due to SSL CPU cycles. I do realize now that my question is too simplistic and obviously varies according to the nature of the application, server config, etc. So won't expect any answers for it. :)
  - michaelmior 14y ago
    Definitely a question I can't answer. Although these days SSL is rarely implemented on each individual server. Instead, load balancers handle SSL and traffic is passed unencrypted to the backend servers doing the real work (presumably at this point, you're on a secure network). Many hardware load balancers even have specialized chips for handling SSL.
  - ams6110 14y ago
    Just a guess but if you are running your site on a single server you're going to hit other bottlenecks in things such as your application code or database, your http server, or disk contention, or RAM starvation, before SSL encryption becomes the overriding one.
- mbrameld 14y ago
  According to Google that's not true. "In order to do this we had to deploy no additional machines and no special hardware. On our production front-end machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." https://www.verisign.com.au/ssl/ssl-information-center/ssl-resources/whitepaper-protect-sidejacking/index.html https://www.verisign.com.au/ssl/ssl-information-center/ssl-r...

EvanAnderson 14y ago

I'm a little disappointed with the answers from Zypher (one of the Stack Exchange sysadmins) and Jeff Atwood. Particularly troublesome is Jeff's statement "If you have a 'man in the middle' then there are deeper problems, like, you're using a compromised network." I'd argue that it's appropriate, from a security architecture perspective, to treat the entire Internet as a "compromised network". Admittedly, my use-case for the Stack Exchange sites (specifically Server Fault) is a little different than most people's and I'm a lot more worried about "theft" of my "identity" there than most people would be. Still, though, I'd like to see the answer revisited in light of mid-2012 technology / costs. I suppose I should go post something over there...