Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Why don't we see more HTTPS? Is CPU an issue?
26 points by agl on Sept 10, 2009 | hide | past | favorite | 31 comments
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



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?


>> Breaks any web-caching by a proxy

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.


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.


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


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


There may be only a few forms that have passwords, but every request includes your session cookie. An eavesdropper could hijack your session.

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.


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, ...).


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?


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.


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.


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


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


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.


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.


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


It's not the cost of the certificate that's the issue. It's the SSL bandwidth overhead.


Good point, I had not even thought about that angle.


They came down, but now there are EV SSL certs that are still a couple hundred dollars/yr for a non-wildcard cert.

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.


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.


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.


SNI (Server name indication)[1] is designed to fix this. It's a TLS extension which lets the server know the hostname that the client is expecting. It can then reply with the correct certificate.

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


Reading everyone's reasons for not implementing SSL, I'm wondering, how do you handle user logins? I'm building a site right now, and I need to create user accounts, and allow them to login with a username/password. Seems irresponsible to have them pass their password as cleartext when they log in. What do you do instead?


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.


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


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


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


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)


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


Huh? There is no cost for an elastic IP address when it is in use.


But there is a cost for running a separate instance for every IP since Amazon won't let you assign more than one address per instance.


Thanks! I did lose points for this w/o clarifying..

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.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: