
StatusNet suggests HTTPS be a paid feature because it's "difficult to scale". - mfukar
http://identi.ca/conversation/57103449
======
jrockway
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.

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

~~~
tav
[http://github.com/downloads/tav/ampify/distfile.openssl-0.9....](http://github.com/downloads/tav/ampify/distfile.openssl-0.9.8o.tar.bz2)

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

~~~
jrockway
Ah, patched versions of OpenSSL. Those _never_ cause problems...

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

