Ask HN: Why don't we see more HTTPS? Is CPU an issue?
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
[ 2.5 ms ] story [ 51.9 ms ] threadAlso, you might be interested in: http://bench.cr.yp.to/index.html
Wildcard certificates have come down as low as $200 a year, very recently.
The price issue is mostly perception at this point, but like they say, perception is reality. I would gamble that most people don't realize how much cheaper SSL certification has become.
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.
I suppose that depends on the data. $500 keeps one of my servers running for 6 months. For a bank the security is very useful. For a site like HN where the only sensitive data is the password, it isn't so much.
As a business owner, I feel a bit like it's a big con game, as I have trouble understanding what it is that EV SSL certs solve that wasn't supposed to be solved with the original SSL certs. It could just be my ignorance, but I still find $400/yr to file some papers and then do some math a bit absurd.
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.
Precisely the type of details you'd had to figure out. For my current (very rudimentary) understanding of SSL that doesn't matter. Setting it up myself would mean I would have to know such things and more.
As for costs: We have several IPs and our hosting costs are about 70 euros/month/server. Still, I wouldn't shell out the 100 bucks per year simply because it's lost money. It doesn't solve any of my problems and my users don't care, or at least seem to not care.
I believe that to be the main reason. Users don't care. Tech people care, sometimes. Sometimes a site owner cares (banks etc.), but most of the time no one really cares too much about it. And when you think about it, if nobody cares, is it really a problem?
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.
However, I note from the Wikipedia page that XP doesn't support this (!). I had thought this a solved problem :(
[1] http://en.wikipedia.org/wiki/Server_Name_Indication
I run multiple sites on a single instance (we're a webhost) We don't do shopping carts/ssl for our clients, because that would cost 1 - Small Instance/month, which is cost-prohibitive for them.
We are using the 1 static IP for our own SSL certificate.
See: (http://aws.amazon.com/ec2/#pricing)
In terms of downside, SSL adds latency (ignore CPU time for now, it adds a further 2+ RTT times for the CLIENT_HELLO and SERVER_HELLO + cipher negotiation/key exchange on connection. Breaks (until SNI becomes about) HTTP Host based virtual servers. Breaks any web-caching by a proxy, and in many cases by the browser (most browsers don't use their disk cache for SSL content).
All that downside, for what upside? Yes - for the few forms where someone submits passwords or other private data, yes. But why on earth would you want to use SSL otherwise?
If I want to browse with TOR, it's pretty likely the exit nodes are sniffing my data. It kind of defeats the purpose of using TOR if I can't stay on HTTPS.
This is actually a pretty great upside often. Using SSL means that you can be reasonably sure that nothing is messing with your data in transit - caching, modifying, etc.
Free wifi that modifies html pages and adds adverts? Just use ssl instead.
Some firewalls that block based on keywords in pages etc - use SSL instead.
a) What site(s) you were accessing (the IP address is visible, and as it can't be a shared IP, a DNS lookup or SSL connect to that site should give them what site) and the length of time on each site. b) The approximate size of those pages, and the number of embedded items, so could quite probably and within reasonable time know what pages. c) If they knew your browser (through seeing non SSL traffic) they could probably know the length of the URL.
Have you really gained anything through using SSL??
For most, the big problem is the all or nothing decision. Most end users don't like the browser asking about switching protocols, for example, for the login or credit card process. So the easy choice is to use https for everything. But that's a waste, most of your requests don't need it. But there is lots of waste that buys you value: ruby, multi-layered frameworks and libs, etc.