StatusNet suggests HTTPS be a paid feature because it's "difficult to scale". | Hacker News Reader

StatusNet suggests HTTPS be a paid feature because it's "difficult to scale".

identi.ca

32 pointsmfukar13 comments

Is scaling https that difficult? You do the SSL on your load-balancer; modern Intel chips can do AES at over 2 gigabytes per second per core.

As far as I know the expensive part is not the transmission of data (which is done via AES and extremely cheap), but the establishment of the SSL connection using public key cryptography. Even though this only needs to be done once for each "incoming" user, due to persistent connections.

What StatusNet said, that they have problem not with CPU power, needed for SSL handshakes, but with implementing load balancing. Unfortunately, linked discussion is non-informative on subject, just saying "...gets really complicated".

"Really complicated" is possibly related to having to decrypt/reencrypt to HTTP at every hop. Otherwise all but the last node are basic pipes.

Uh, no? It's SSL from the user to the load balancer. It's cleartext from the load balancer to the backend servers. There is only one SSL hop; over the insecure internet from your frontend server to the user. Once you are on the physically-secure local network, you don't need SSL anymore.

HTTP and HTTPS are end-to-end, care to clarify what you meant by "at every hop"?

Nowadays not so much on the computation side (even handshaking is fast), but for mass virtual hosting it is very annoying/difficult without SNI (need so resort to multiple ips or having wildcard certificates and running under subdomains). In a SNI enabled world it wil be much cheaper.

This should not be a problem in the status.net case, where users are assigned subdomains (username.status.net). Just get a wildcard certificate for *.status.net.

From reading the recent 'ImperialViolet' article titled 'Overclocking SSL' about Google's efforts, it seems the issues are that:

- unless you use the recently patched version, OpenSSL uses an overhead of 50KB per connection; even with the patch, it's 5KB. (It's not clear if this 'connection' overhead is also the size of the 'session' data which must be cached for followup handshakes to go faster.)

- in all cases using commonly-available software, SSL adds roundtrips to connection-establishment, and thus latency for the end-user. Minimizing this requires carefully choosing how you handle certificates and how you cache session info, and having a large or shared session cache may need different load-balancing than sites already use.

- Google has several proposals (all dated 2010) for further reducing or in some cases eliminating roundtrips; no implementations other than in Google Chrome and Google's frontend servers were mentioned by the 'Overclocking' article.

So there's still an adjustment cost, new overhead costs, and a latency cost, for adopting SSL. You can minimize these by doing-as-Google-does, but the software to do so is not yet freely available.

http://github.com/downloads/tav/ampify/distfile.openssl-0.9....

^ Patched version of OpenSSL for the various optimisations...

Ah, patched versions of OpenSSL. Those never cause problems...

SpiderOak has always been an all-SSL site, for all services (including data storage and retrieval.)

We've found the Erlang implementation of SSL scales more comfortably than OpenSSL. (The new Erlang implementation, available since r12, and the default in r14, isn't just a wrapper for OpenSSL.)

All of the discussion suggests strongly to me that their implementation may be flawed / rushed / poorly scalable in the first place.

Not to say implementing it wouldn't slow things down slightly, nor that it doesn't add extra difficulty to scaling. But there are plenty of very large sites out there with https, and plenty of medium-size, quickly-grown, heavily-virtualized hosts out there with https available everywhere. It can't be that difficult unless you're making it harder for yourself.

Reply on news.ycombinator.com