5 ms·

"The performance complaint is long debunked" - There are still performance hits. - There are still two additional round trips on the first https connection vs

"The performance complaint is long debunked" - There are still performance hits. - There are still two additional round trips on the first https connection vs http. That means there are still cases where http is faster than https, even when using spdy/http2. - Also, the initial (before an HSTS header is seen) redirect from http -> https when typing in a domain name adds to the overall first load time. Even after the performance and maintenance issues, we still have the local-development issue (developing on 127.0.0.1). You still need to own a domain name to get a cert from Let's Encrypt. I'm happy Let's Encrypt is making certs easier so we can start focusing on the _next_ hurdles of massive TLS adoption. :)

TazeTSchnitzel 11y ago
> There are still two additional round trips on the first https connection vs http. Not with HSTS preload.
- collinmanderson 11y ago
  True
- pas 11y ago
  How. How is that thing still considered a solution? We are talking about Chrome's HSTS preload, right? How come downloading all the Internet's certs with a browser is considered at all? Yes, it's nice, but it's a bigger hack than Win95's GUI on MSDOS.
- toast0 11y ago
  HSTS preload doesn't reduce the preamble to a TLS connection: You have to send the TLS client hello, wait for the TLS server hello back (1 Round trip), send the handshake finished, wait for the server handshake finished (2nd round trip), before sending application data. TLS 1.3 is supposed to help with that (although I haven't read the spec), but that's probably just bringing it down to one extra round trip in the common case. Add tcp (one round trip), and http (one round trip), and it's four round trips, twice as many as plain http. If you are serving us users on broadband, and you only have servers on one side of the country, half of your users are going to see about 80 ms round trip, so https slows down your first page load by 160 ms, even before you worry about encryption. If you have users around the world, and servers in only one location, you're likely to see many users with 250ms or 300 ms, an very simple https page (short request, short response) is going to take a minimum of 1 second (2 round trips for tls, one for tcp, and one for http), and if your users are on congested mobile networks, ouch.
  - collinmanderson 11y ago
    It doesn't reduce the TLS connection, but it reduces two round trips for the HTTP->HTTPS redirect. If the link is https in the first place then it's not a problem, but if you type in a domain name it will try HTTP first before starts the TLS connection.
technion 11y ago
I should clarify the performance issue. A lot of developers, even today, come to me asking for a server configured to run a specific directory over SSL, with the rest of the site over plaintext. The argument I am always given is that SSL will tax the CPU and the site won't be able to scale. I'm told it's a best practice and people will viciously defend "wasting" performance on parts of the site that don't need it. It's not a common recommendation here, where people are arguably more aware of modern practices. But amongst a lot of the population of entry level web developers I run into, it's a very common one, and it's also very wrong. The "round trip" issue however that you point to, is totally valid, but also one that will not kill a site's ability to scale.
- toast0 11y ago
  TLS absolutely does tax the CPU. Netflix published a paper [1] about the work they did to scale TLS in their cache appliances; after their work, they were able to get 10Gbps of https traffic out of a system that was previously limited by its network interfaces to serving 40Gbps of http traffic. That certainly doesn't apply to everyone, a lot of people are using more CPU to generate their content than to serve it; in that case, maybe adding some extra CPU to encrypt isn't going to have a big effect. Extra round trips can also affect the ability to scale: you'll need to be able to handle more connections open at a time, since each one will take longer to get the request to you. This is probably minor, unless you're on the edge of the number of connections your system can handle. [1] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

TazeTSchnitzel 11y ago

> There are still two additional round trips on the first https connection vs http. Not with HSTS preload.

collinmanderson 11y ago
True
pas 11y ago
How. How is that thing still considered a solution? We are talking about Chrome's HSTS preload, right? How come downloading all the Internet's certs with a browser is considered at all? Yes, it's nice, but it's a bigger hack than Win95's GUI on MSDOS.
toast0 11y ago
HSTS preload doesn't reduce the preamble to a TLS connection: You have to send the TLS client hello, wait for the TLS server hello back (1 Round trip), send the handshake finished, wait for the server handshake finished (2nd round trip), before sending application data. TLS 1.3 is supposed to help with that (although I haven't read the spec), but that's probably just bringing it down to one extra round trip in the common case. Add tcp (one round trip), and http (one round trip), and it's four round trips, twice as many as plain http. If you are serving us users on broadband, and you only have servers on one side of the country, half of your users are going to see about 80 ms round trip, so https slows down your first page load by 160 ms, even before you worry about encryption. If you have users around the world, and servers in only one location, you're likely to see many users with 250ms or 300 ms, an very simple https page (short request, short response) is going to take a minimum of 1 second (2 round trips for tls, one for tcp, and one for http), and if your users are on congested mobile networks, ouch.
- collinmanderson 11y ago
  It doesn't reduce the TLS connection, but it reduces two round trips for the HTTP->HTTPS redirect. If the link is https in the first place then it's not a problem, but if you type in a domain name it will try HTTP first before starts the TLS connection.

technion 11y ago

I should clarify the performance issue. A lot of developers, even today, come to me asking for a server configured to run a specific directory over SSL, with the rest of the site over plaintext. The argument I am always given is that SSL will tax the CPU and the site won't be able to scale. I'm told it's a best practice and people will viciously defend "wasting" performance on parts of the site that don't need it. It's not a common recommendation here, where people are arguably more aware of modern practices. But amongst a lot of the population of entry level web developers I run into, it's a very common one, and it's also very wrong. The "round trip" issue however that you point to, is totally valid, but also one that will not kill a site's ability to scale.

toast0 11y ago
TLS absolutely does tax the CPU. Netflix published a paper [1] about the work they did to scale TLS in their cache appliances; after their work, they were able to get 10Gbps of https traffic out of a system that was previously limited by its network interfaces to serving 40Gbps of http traffic. That certainly doesn't apply to everyone, a lot of people are using more CPU to generate their content than to serve it; in that case, maybe adding some extra CPU to encrypt isn't going to have a big effect. Extra round trips can also affect the ability to scale: you'll need to be able to handle more connections open at a time, since each one will take longer to get the request to you. This is probably minor, unless you're on the edge of the number of connections your system can handle. [1] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf