16 ms·

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

32 points by mfukar 16y ago

jrockway 16y ago
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.
- gst 16y ago
  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.
  - drdaeman 16y ago
    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".
    - xuhu 16y ago
      "Really complicated" is possibly related to having to decrypt/reencrypt to HTTP at every hop. Otherwise all but the last node are basic pipes.
      - jrockway 16y ago
        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.
      - mfukar 16y ago
        HTTP and HTTPS are end-to-end, care to clarify what you meant by "at every hop"?
- michaelneale 16y ago
  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.
  - gst 16y ago
    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.
- gojomo 16y ago
  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 16y ago
    http://github.com/downloads/tav/ampify/distfile.openssl-0.9.8o.tar.bz2 http://github.com/downloads/tav/ampify/distfile.openssl-0.9.... ^ Patched version of OpenSSL for the various optimisations...
    - jrockway 16y ago
      Ah, patched versions of OpenSSL. Those never cause problems...
  - rarrrrrr 16y ago
    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.)
Groxx 16y ago
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.

32 points by mfukar 16y ago

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.

gst 16y ago
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.
- drdaeman 16y ago
  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".
  - xuhu 16y ago
    "Really complicated" is possibly related to having to decrypt/reencrypt to HTTP at every hop. Otherwise all but the last node are basic pipes.
    - jrockway 16y ago
      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.
    - mfukar 16y ago
      HTTP and HTTPS are end-to-end, care to clarify what you meant by "at every hop"?
michaelneale 16y ago
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.
- gst 16y ago
  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.
gojomo 16y ago
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 16y ago
  http://github.com/downloads/tav/ampify/distfile.openssl-0.9.8o.tar.bz2 http://github.com/downloads/tav/ampify/distfile.openssl-0.9.... ^ Patched version of OpenSSL for the various optimisations...
  - jrockway 16y ago
    Ah, patched versions of OpenSSL. Those never cause problems...
- rarrrrrr 16y ago
  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.)

Groxx 16y ago

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.