4 ms·

> The CPU overhead of TLS encryption has historically been significant. We’ve done a lot of work behind the scenes to improve both the software and hardware lay

> The CPU overhead of TLS encryption has historically been significant. We’ve done a lot of work behind the scenes to improve both the software and hardware layers to minimise the load impact of TLS whilst also improving security. I thought that it hasn't been significant overhead for a while now? related: https://www.maxcdn.com/blog/ssl-performance-myth/ https://www.maxcdn.com/blog/ssl-performance-myth/ https://istlsfastyet.com/ https://istlsfastyet.com/

blowski 10y ago
> Even a 2012 MacBook Air can sign an SSL key in only 6.1 milliseconds. The BBC has to deal with machines much older and much less powerful than that.
- Buge 10y ago
  Every TLS speed concern I've heard has been about the server speed, not the client speed. The servers shouldn't be running on old MacBook airs.
  - multjoy 10y ago
    It is the BBC
- jpetrucc 10y ago
  Even if it took an ancient machine 10x longer than a 2012 MacBook air, that 61 milliseconds more is really not all that much time in the grand scheme of things. I'm sure the people using these machines that are "much older and much less powerful" than a 2012 macbook air are not expecting sites to load as fast as a newer machine, and probably don't care about the loss of less than 0.1 seconds to load time. If you're running a 6+ year old machine and expecting high performance you'd have to be insane. Even if BBCOnline cared this intensely about performance, there are more than a few other things they could do to speed everything up. The switch from Apache to NGINX for one. I know that this takes many more developer/sysadmin hours, but if they really cared about a tens of milliseconds then it is definitely something they'd invest in. NGINX has quite a lot of support and is very stable, as well as generally known to much faster than Apache in most cases [1]. It's also not like NGINX is a hipster/unused server, it has quite a respectable share of the 'market' [2]. I also noticed on this page that they docwrite a script (probably to force it async?). This type of 'hack' is terrible for performance [3]. You could just add the 'async' attribute to the script tag and actually move it in the html and reduce the cycles wasted by a hacky solution. [1]: https://www.rootusers.com/web-server-performance-benchmark/ https://www.rootusers.com/web-server-performance-benchmark/ [2]: http://news.netcraft.com/archives/2016/03/18/march-2016-web-server-survey.html http://news.netcraft.com/archives/2016/03/18/march-2016-web-... [3]: https://www.stevesouders.com/blog/2012/04/10/dont-docwrite-scripts/ https://www.stevesouders.com/blog/2012/04/10/dont-docwrite-s...
  - dtemp 10y ago
    I think the best thing you can do to speed up HTTPS is to move to HTTP/2. Check this out: https://www.httpvshttps.com/ https://www.httpvshttps.com/
dtemp 10y ago
I can see they've only enabled Elliptic Curve Diffie-Hellman Ephemeral and RSA key exchange cipher suites. That means users will either use ECDHE and get forward secrecy, or old clients will just use "RSA" (which means the client sends a "pre-key" back to the server encrypted with the server's public key) which works but doesn't give you forward secrecy. What they HAVEN'T enabled is Diffie-Hellman Ephemeral suites, which give older clients forward secrecy at a big CPU hit. So this is an example of performance-tuning your TLS settings. There's also stuff to do with session tickets, session resumption, and eventually they'd also be served using ECDSA certs, once all clients support it, or there is at least a great way to only show the older RSA cert to old clients.

blowski 10y ago

> Even a 2012 MacBook Air can sign an SSL key in only 6.1 milliseconds. The BBC has to deal with machines much older and much less powerful than that.

Buge 10y ago
Every TLS speed concern I've heard has been about the server speed, not the client speed. The servers shouldn't be running on old MacBook airs.
- multjoy 10y ago
  It is the BBC
jpetrucc 10y ago
Even if it took an ancient machine 10x longer than a 2012 MacBook air, that 61 milliseconds more is really not all that much time in the grand scheme of things. I'm sure the people using these machines that are "much older and much less powerful" than a 2012 macbook air are not expecting sites to load as fast as a newer machine, and probably don't care about the loss of less than 0.1 seconds to load time. If you're running a 6+ year old machine and expecting high performance you'd have to be insane. Even if BBCOnline cared this intensely about performance, there are more than a few other things they could do to speed everything up. The switch from Apache to NGINX for one. I know that this takes many more developer/sysadmin hours, but if they really cared about a tens of milliseconds then it is definitely something they'd invest in. NGINX has quite a lot of support and is very stable, as well as generally known to much faster than Apache in most cases [1]. It's also not like NGINX is a hipster/unused server, it has quite a respectable share of the 'market' [2]. I also noticed on this page that they docwrite a script (probably to force it async?). This type of 'hack' is terrible for performance [3]. You could just add the 'async' attribute to the script tag and actually move it in the html and reduce the cycles wasted by a hacky solution. [1]: https://www.rootusers.com/web-server-performance-benchmark/ https://www.rootusers.com/web-server-performance-benchmark/ [2]: http://news.netcraft.com/archives/2016/03/18/march-2016-web-server-survey.html http://news.netcraft.com/archives/2016/03/18/march-2016-web-... [3]: https://www.stevesouders.com/blog/2012/04/10/dont-docwrite-scripts/ https://www.stevesouders.com/blog/2012/04/10/dont-docwrite-s...
- dtemp 10y ago
  I think the best thing you can do to speed up HTTPS is to move to HTTP/2. Check this out: https://www.httpvshttps.com/ https://www.httpvshttps.com/

dtemp 10y ago

I can see they've only enabled Elliptic Curve Diffie-Hellman Ephemeral and RSA key exchange cipher suites. That means users will either use ECDHE and get forward secrecy, or old clients will just use "RSA" (which means the client sends a "pre-key" back to the server encrypted with the server's public key) which works but doesn't give you forward secrecy. What they HAVEN'T enabled is Diffie-Hellman Ephemeral suites, which give older clients forward secrecy at a big CPU hit. So this is an example of performance-tuning your TLS settings. There's also stuff to do with session tickets, session resumption, and eventually they'd also be served using ECDSA certs, once all clients support it, or there is at least a great way to only show the older RSA cert to old clients.