Ask HN: Why don't we see more HTTPS? Is CPU an issue?

26 points

17 years ago

I'm considering if I should put time into making SSL handshakes faster (by using more modern primitives). I get conflicting reports about whether the lack of common HTTPS support (https://news.ycombinator.com doesn't connect, for example) is exacerbated by the CPU load of performing handshakes.

Here are the numbers:

ECRYPT says that 1248-bits is the "Smallest general-purpose"[1] modulus size these days. Well tuned HTTPS sites (Google, Amazon) will negotiate RSA/RC4/SHA1 [2]. Google uses a 1024-bit key, Amazon has a 2048-bit key.

An SSL handshake with cipher-suites that involve RSA require an RSA private-key operation on the server[3]. The ECRYPT benchmarks suggest that a 2048-bit RSA private-key operation takes about 14Mcycles on a Core2 [4], which is about 158 ops/sec/core. (You can also run `openssl speed rsa` to get numbers for your system.)

So, if you run a non-trivial website, my questions are:

* Why don't you support HTTPS (if you don't) * How much is a problem is the CPU load of HTTPS (if you do), and do you worry about getting slashdotted? * How many connections/second/core do you handle (if you're willing to reveal such information)

Cheers

[1] http://www.keylength.com/en/3/ [2] `openssl s_client -connect mail.google.com:443` [3] RFC 5632, 8.1.1 [4] http://bench.cr.yp.to/web-impl/amd64-margaux-crypto_encrypt.html

31 comments