Why HTTPS for Everything?

Re:Why HTTPS for Everything? by hannob on Monday January 02, 2017 @12:58PM (#13302913)

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.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by jlgaddis on Monday January 02, 2017 @02:56PM (#13303890)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by umanwizard on Monday January 02, 2017 @07:03PM (#13305554)

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.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by vitus on Monday January 02, 2017 @07:40PM (#13305725)

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.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by majewsky on Tuesday January 03, 2017 @09:02AM (#13309166)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by umanwizard on Monday January 02, 2017 @01:23PM (#13303138)

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?

[ Parent | on HN ]

Re:Why HTTPS for Everything? by hannob on Monday January 02, 2017 @02:17PM (#13303590)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by umanwizard on Monday January 02, 2017 @02:50PM (#13303842)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by konklone on Monday January 02, 2017 @03:01PM (#13303944)

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/

[ Parent | on HN ]

Re:Why HTTPS for Everything? by hannob on Monday January 02, 2017 @03:09PM (#13304018)

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

[ Parent | on HN ]