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

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

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/ for more.

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.

You're thinking of 1.2. 1.3 isn't finalized yet.

Huge JS ad injectors, JS template renderers and other dynamic stuff adds about 100x more latency on most web pages than anything TLS related.

Not for first-byte latency.

If you care about client-side latency you should be using HTTP/2. And HTTP/2 is HTTPS-only.

HTTP/2 is not HTTPS-only, the browsers implementations may be.

https://http2.github.io/faq/#does-http2-require-encryption

it's HTTPS-only in all browsers that support it. http://caniuse.com/#feat=http2

Not supported on IE8. Total deal breaker.

IE8 is not supported, along with Windows XP.

so?

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.

> subsequent connections

What if most of your users are first-time visitors coming from google results?

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.

The overhead is so small that it's basically irrelevant if you are not youtube or netflix. If you have a performance problem with https then either you have a flaw in your software or some serious configuration mistake.

In practice in many situations you can even get better performance with HTTPS, because many modern features (for performance notably HTTP/2 and Brotli) aren't available over plain HTTP.

Yep, Netflix even switched to 100% HTTPS for video streams (and the sky didn't fall) [0].

[0]: http://techblog.netflix.com/2016/08/protecting-netflix-viewi...

Netflix has performance needs that are not representative of every site in the world. For example, first-byte latency probably doesn't matter much for them.

Youtube uses QUIC for most of its comms (to Chrome and to the Android YT player; possibly to the iOS one too, I don't remember), which does implement TLS with 0-1 RTTs for connection setup (practically speaking, no additional delay).

And IIRC, encryption overhead is pretty insignificant if you have a CPU with AES instructions, which is to say, pretty much anything from the past 5+ years.

> pretty much anything from the past 5+ years

With a cave-at: Intel's low-cost CPUs didn't include AES-NI until pretty recently. Which is why, in 2014, I went for a cheap Athlon instead of a Celeron for my custom-built homeserver with full-disk encryption.

I worked for junglee.com (a relatively unknown site owned by Amazon that used very little CPU) and extra latency on HTTPS was a massive, serious issue.

What flaw in our software or serious configuration mistake do you think we had?

Based on the current configuration: No OCSP stapling and no elliptic curve key exchange.

Also your setup suffers from TLS version intolerance, which by itself isn't a performance issue, but it is a hint that you're using a badly written TLS stack.

https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s...

And how much do those increase first byte latency? (which is the real problem)

Tough to say without knowing more about the stack. But in terms of first byte latency, some things you can look at:

* TLS False Start

* HTTP/2 + ALPN

* Optimizing TLS record size

Some 2013-era advice for nginx here: https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-...

And some other advice and links here: https://istlsfastyet.com/

Pretty much all of them matter for first byte latency. OCSP & the key exchange both happen before any data can be exchanged.

HTTP/2 significantly reduces the issue of repeated handshakes. See: https://www.httpvshttps.com/

Obviously, that site is picking a specific case to make a point, but the point is significant.

The existence of the request itself (for the handshake) is most of the cost. If a client is on the other side of the world, hundreds of ms. Otherwise if you have servers everywhere, still probably 50-70ms for the handshake.

Edit: in my experience.

    "TLS has exactly one performance problem: it is not used widely enough"

https://istlsfastyet.com/

Downvoted.

The information in that site doesn't actually back up the headline. It handwaves away the extra-round-trip issue with "well, there are experimental ways in the works to eliminate one of those extra round trips" which is worlds away from saying there are "no performance problems" with TLS in practice.