

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

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.<p>Here are the numbers:<p>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.<p>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.)<p>So, if you run a non-trivial website, my questions are:<p>* 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)<p>Cheers<p>[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
======
adamt
Why though - would anyone want to browser a site like news.ycombinator.com
over SSL? The vast majority of web data is public data so encryption is of
little value, and due to the way SSL works, then there's arguably little value
in SSL for authentication (if someone can hack the site, they can generally
apply/install for a new SSL cert easily enough). In terms of privacy, SSL
gains little - given that SSL breaks Host based virtual hosting, then
accessing dodgysite.com's IP address lets a man in the middle know (almost) as
much as about your browsing habits as accessing the site without SSL.

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?

~~~
wglb
If I am reading stuff at the library or other public wifi (says right hear
"The Library's wireless network is not secure") I don't want eavesdroppers to
know.

~~~
adamt
Even with SSL though, an eavesdropper would know:

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??

~~~
wglb
They don't see the content coming or going. That to me is pretty significant.

------
scumola
Most larger companies have an "SSL Accelerator" which is usually part of a
router/switch/load-balancer. This device does SSL in hardware, so it can do
the offloading much faster and let the web servers and app servers worry about
serving-up the app and doing that work. Most SSL Accelerators can do millions
of connections without working too hard, so it's possible at large scale for
larger websites without really worrying about CPU on the server-side. I'll bet
that they just don't worry about SSL except for when it's absolutely necessary
(personal info - login, purchase, ...).

------
uptown
Can somebody lend some insight into how SSL certs function for international
users? I've had no problems with the inexpensive SSL certificates with
domestic (US) users, but I've had complaints of users accessing things from
other countries. Do SSL certs not function the same globally? Is it common for
the CA's to not be globally accepted?

------
lucumo
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.

~~~
klodolph
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.

~~~
lucumo
_> Nitpicky: You don't get a key somewhere. You make your own keypair, and
send the public key off to be signed._

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?

------
tsally
Companies would rather not spend the money. It's as simple as that.

Also, you might be interested in: <http://bench.cr.yp.to/index.html>

~~~
prosa
Single-domain certificates are cheap. RapidSSL charges $79/year, and you can
do better.

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.

~~~
donw
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.

~~~
lucumo
_> 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._

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.

------
jhancock
For most startups, the performance hit is not a big deal. If your a serious
startup, you need your own IP, so this shouldn't be a roadblock. Setup is not
hard. If you can't setup an SSL cert, how are you going to manage the rest of
your server concerns? Cost of the cert? This is a drop in the bucket compared
to the rest of your startup.

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.

------
trezor
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.

~~~
donw
If you're like most newer startups that have their customers under a TLD
(foo.mycorp.com, bar.mycorp.com), you can use wildcard SSL to manage the
problem. Otherwise, yeah, you're looking at one IP per TLD.

~~~
kdw
Am I correct in thinking that a wildcard only gets you one level deep? e.g.
that *.mycorp.com matches "foo.mycorp.com" but not "foo.bar.mycorp.com"?

~~~
bensummers
Depends on the browser, which in practice means just one level deep.

------
izak30
I don't support more HTTPS because of the cost of static IPs on EC2 (i.e.
~72/mo)

~~~
astrodust
Elastic IPs are $7/mo. only if they are unused. They cost nothing if attached
to a running EC2 instance.

See: (<http://aws.amazon.com/ec2/#pricing>)

~~~
izak30
Yeah, I know, but you can only attach one per instance, so the effective cost
per elastic ip per month is 1 small instance.

