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

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

I don't worry about CPU. What I do worry about is cost and most of all the amount of effort required to set it up. You'd have to get a key somewhere (figure out where you get one that is both supported by most important browsers and as cheap as possible), install it (probably an afternoon's worth of work, mostly because of researching how) and then test it.

Cost is important too. As a small start-up we adhere to the principle that a penny saved is a penny earned.

Combine all that with the fact that there's no real demand for more security on our sites and you'll come to the conclusion that it just isn't worth the time and money spent on it. We're not running a bank, so it's not all that important anyway.

For HTTPS you need a dedicated IP since security negotiation happens before the HTTP hosts header is posted and your cert needs to cover the host you want to connect to. That is, it is impossible to host several sites using HTTPS on one single IP. HTTPS using SSL (instead of for instance TLS) means that this is a limitation built into HTTPS itself and can't be mitigated.

With the current shortage on IPv4 IPs and most shared hosters trying to squeeze as many websites as possible onto the same single IP, that effectively means that getting a site up and running with HTTPS (and that is not even mentioning the cost of getting a properly signed certificate) is very, very costly and hard compared to regular HTTP hosting.

Until IPv6 goes mainstream don't expect any of this to change.

I agree that it's all perception, and that even with wildcard SSL at $500/year (what the cost has traditionally been), it's worth it to protect your customers' data.

What scares me are companies that allow a front 'login' page on a non-SSL domain, and have everything else on their domain name via https, allowing for easy man-in-the-middle attacks.

Nitpicky: You don't get a key somewhere. You make your own keypair, and send the public key off to be signed. It costs ~$100/year + you need an IP address, compare that to what I pay for shared hosting ($75/year including domain) and you get your answer.