Why HTTPS for Everything?

Re:Why HTTPS for Everything? by notatoad on Monday January 02, 2017 @12:59PM (#13302921)

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

[ Parent | on HN ]

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

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by derf_ on Monday January 02, 2017 @02:27PM (#13303671)

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.

[ Parent | on HN ]

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

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.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by xorcist on Monday January 02, 2017 @03:28PM (#13304187)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by izacus on Monday January 02, 2017 @04:09PM (#13304552)

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

[ Parent | on HN ]

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

Not for first-byte latency.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by notatoad on Monday January 02, 2017 @02:22PM (#13303633)

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by hrbrtglm on Monday January 02, 2017 @02:51PM (#13303847)

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

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by notatoad on Monday January 02, 2017 @02:55PM (#13303881)

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

[ Parent | on HN ]

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

Not supported on IE8. Total deal breaker.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by HelloNurse on Tuesday January 03, 2017 @05:30AM (#13308213)

IE8 is not supported, along with Windows XP.

[ Parent | on HN ]

Re:Why HTTPS for Everything? by umanwizard on Tuesday January 03, 2017 @05:14PM (#13313655)

so?

[ Parent | on HN ]

Re:Why HTTPS for Everything? by snuxoll on Monday January 02, 2017 @01:46PM (#13303341)

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.

[ Parent | on HN ]

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

> subsequent connections

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

[ Parent | on HN ]

Re:Why HTTPS for Everything? by snuxoll on Monday January 02, 2017 @09:39PM (#13306243)

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.

[ Parent | on HN ]