12 ms·

1024bit certificates are only valid until December this year. Then we have to use 2048bit, destroying the benefit we get from faster computers. You need SSL ac

1024bit certificates are only valid until December this year. Then we have to use 2048bit, destroying the benefit we get from faster computers. You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine. This is one of the places cost comes from.

nl 14y ago
You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine. That's not true - or rather it conflates two unrelated problems. 1) HTTPS/SSL (even with larger certificates) isn't computationally expensive: In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend 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.[1] 2) The HTTPS initial handshake is slow. However, this isn't because of the power of the machine, or the certificates size. It's cause by round-trip overheard (See [2]). The solution for that is to reuse HTTPS connections as much as possible (which both your server and the browser should try to do for you anyway. But doing things like using the same hostname can help) [1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht... [2] http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame2.doc_5.1/ss7aumst18.htm http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?to...
- benjiweber 14y ago
  Re-using HTTPs connections is only helpful when you have repeat requests from the same user. It's actually counter productive for tracking beacons or ad impressions, where you rarely see the same user twice in rapid succession. For web applications the overhead is much less significant. Both because you can re-use connections, and because few web applications can manage 20k+ requests per second on low end hardware.
StavrosK 14y ago
> destroying the benefit we get from faster computers. That's precisely the point, though.
Retric 14y ago
2048bit is not all that much harder to encrypt than 1024bit you might go from 1% CPU to 2% CPU but that's about it.

nl 14y ago

You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine. That's not true - or rather it conflates two unrelated problems. 1) HTTPS/SSL (even with larger certificates) isn't computationally expensive: In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend 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.[1] 2) The HTTPS initial handshake is slow. However, this isn't because of the power of the machine, or the certificates size. It's cause by round-trip overheard (See [2]). The solution for that is to reuse HTTPS connections as much as possible (which both your server and the browser should try to do for you anyway. But doing things like using the same hostname can help) [1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht... [2] http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame2.doc_5.1/ss7aumst18.htm http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?to...

benjiweber 14y ago
Re-using HTTPs connections is only helpful when you have repeat requests from the same user. It's actually counter productive for tracking beacons or ad impressions, where you rarely see the same user twice in rapid succession. For web applications the overhead is much less significant. Both because you can re-use connections, and because few web applications can manage 20k+ requests per second on low end hardware.

StavrosK 14y ago

> destroying the benefit we get from faster computers. That's precisely the point, though.

Retric 14y ago

2048bit is not all that much harder to encrypt than 1024bit you might go from 1% CPU to 2% CPU but that's about it.