11 ms·

"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users

"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

umanwizard 10y ago
This is only server-side CPU. What about client-side latency? TLS involves extra hops to establish a connection.
- snuxoll 10y ago
  The overhead can be minimized on subsequent connections if you pin a client to one server handling TLS termination for the session (you can either pin to one application server, or a specific load balancer) and your servers have enough memory to keep an adequate number of sessions in memory. You probably take up roughly 10KB of memory per TLS session that's active, so 100 active sessions per 1MB or so which isn't too bad.
  - umanwizard 10y ago
    > subsequent connections What if most of your users are first-time visitors coming from google results?
    - snuxoll 10y ago
      You take an extra hit the first time a TLS session key is established, after that all subsequent HTTP requests can do a fast resume. This has nothing to do with users over a period of time.
- notatoad 10y ago
  If you care about client-side latency you should be using HTTP/2. And HTTP/2 is HTTPS-only.
  - hrbrtglm 10y ago
    HTTP/2 is not HTTPS-only, the browsers implementations may be. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption
    - notatoad 10y ago
      it's HTTPS-only in all browsers that support it. http://caniuse.com/#feat=http2 http://caniuse.com/#feat=http2
  - umanwizard 10y ago
    Not supported on IE8. Total deal breaker.
    - HelloNurse 10y ago
      IE8 is not supported, along with Windows XP.
      - umanwizard 10y ago
        so?
- derf_ 10y ago
  In TLS 1.3, when the client sends its list of supported cipher suites, it guesses which one the server will pick and includes keying material for it in the initial ClientHello. The server does the same in its ServerHello. That reduces a full handshake to 1 round-trip when the guesses are right (vs. 2 RTTs in TLS 1.2). TLS 1.3 also supports 0-RTT connections for servers the client has connected to before using a static "pre-shared key". There is some additional vulnerability to replay attacks (newly introduced with 0-RTT) and loss of forward secrecy (the same as 1-RTT session resumption in TLS 1.2) of the application data sent in the initial ClientHello. The rest of the data sent in the connection has the full set of TLS security guarantees. The pre-shared key approach has less overhead for servers and a simpler synchronization problem for load-balancers than the session IDs and session cookies of TLS 1.2. See, e.g., https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ for more.
  - umanwizard 10y ago
    1 extra round trip is a lot when your users are on shitty connections in India. 0 extra round trips for servers the client has connected to before doesn't matter when most of your users are first-time visitors. Not to mention that TLS 1.3 isn't supported on IE8, a complete deal-breaker for things I've worked on.
    - xorcist 10y ago
      You're thinking of 1.2. 1.3 isn't finalized yet.
  - deleted 10y ago
    [deleted]
- izacus 10y ago
  Huge JS ad injectors, JS template renderers and other dynamic stuff adds about 100x more latency on most web pages than anything TLS related.
  - umanwizard 10y ago
    Not for first-byte latency.

umanwizard 10y ago

This is only server-side CPU. What about client-side latency? TLS involves extra hops to establish a connection.

snuxoll 10y ago
The overhead can be minimized on subsequent connections if you pin a client to one server handling TLS termination for the session (you can either pin to one application server, or a specific load balancer) and your servers have enough memory to keep an adequate number of sessions in memory. You probably take up roughly 10KB of memory per TLS session that's active, so 100 active sessions per 1MB or so which isn't too bad.
- umanwizard 10y ago
  > subsequent connections What if most of your users are first-time visitors coming from google results?
  - snuxoll 10y ago
    You take an extra hit the first time a TLS session key is established, after that all subsequent HTTP requests can do a fast resume. This has nothing to do with users over a period of time.
notatoad 10y ago
If you care about client-side latency you should be using HTTP/2. And HTTP/2 is HTTPS-only.
- hrbrtglm 10y ago
  HTTP/2 is not HTTPS-only, the browsers implementations may be. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption
  - notatoad 10y ago
    it's HTTPS-only in all browsers that support it. http://caniuse.com/#feat=http2 http://caniuse.com/#feat=http2
- umanwizard 10y ago
  Not supported on IE8. Total deal breaker.
  - HelloNurse 10y ago
    IE8 is not supported, along with Windows XP.
    - umanwizard 10y ago
      so?
derf_ 10y ago
In TLS 1.3, when the client sends its list of supported cipher suites, it guesses which one the server will pick and includes keying material for it in the initial ClientHello. The server does the same in its ServerHello. That reduces a full handshake to 1 round-trip when the guesses are right (vs. 2 RTTs in TLS 1.2). TLS 1.3 also supports 0-RTT connections for servers the client has connected to before using a static "pre-shared key". There is some additional vulnerability to replay attacks (newly introduced with 0-RTT) and loss of forward secrecy (the same as 1-RTT session resumption in TLS 1.2) of the application data sent in the initial ClientHello. The rest of the data sent in the connection has the full set of TLS security guarantees. The pre-shared key approach has less overhead for servers and a simpler synchronization problem for load-balancers than the session IDs and session cookies of TLS 1.2. See, e.g., https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ for more.
- umanwizard 10y ago
  1 extra round trip is a lot when your users are on shitty connections in India. 0 extra round trips for servers the client has connected to before doesn't matter when most of your users are first-time visitors. Not to mention that TLS 1.3 isn't supported on IE8, a complete deal-breaker for things I've worked on.
  - xorcist 10y ago
    You're thinking of 1.2. 1.3 isn't finalized yet.
- deleted 10y ago
  [deleted]
izacus 10y ago
Huge JS ad injectors, JS template renderers and other dynamic stuff adds about 100x more latency on most web pages than anything TLS related.
- umanwizard 10y ago
  Not for first-byte latency.