Comments on: SSL is not table salt http://rdist.root.org/2009/03/09/ssl-is-not-table-salt/ Embedded security, crypto, software protection Sat, 13 Mar 2010 14:29:16 +0000 http://wordpress.com/ hourly 1 By: Nate Lawson http://rdist.root.org/2009/03/09/ssl-is-not-table-salt/#comment-4922 Nate Lawson Wed, 11 Mar 2009 01:11:45 +0000 http://rdist.root.org/?p=292#comment-4922 Excellent info, thanks for babbling. :) Excellent info, thanks for babbling. :)

]]> By: Chris Palmer http://rdist.root.org/2009/03/09/ssl-is-not-table-salt/#comment-4921 Chris Palmer Tue, 10 Mar 2009 17:25:53 +0000 http://rdist.root.org/?p=292#comment-4921 Note that pipelining and keep-alive are different things: http://en.wikipedia.org/wiki/HTTP_persistent_connection http://en.wikipedia.org/wiki/HTTP_pipelining While both definitely help performance, browsers apparently can't assume that servers support it (even though "HTTP/1.1 conforming servers are required to support pipelining"). You can turn it on in Firefox in about:config and see if it works well. As for minification (eliminating whitespace and comments and such), it does indeed help, even when combined with compression. One of my clients has an 80KiB front page, 40KiB of which is nothing but whitespace! They gzip the 80 down to 12, but gzipping the minified version gets you down to 9.7 -- a significant savings when you get lots of hits per day. :) There are free tools for minification, and they could be built into filters, and probably have been. Sorry to babble on -- this is one of my favorite topics because it unites security, usability, and performance and shows that the three work together, rather than opposing each other. Note that pipelining and keep-alive are different things:

http://en.wikipedia.org/wiki/HTTP_persistent_connection

http://en.wikipedia.org/wiki/HTTP_pipelining

While both definitely help performance, browsers apparently can’t assume that servers support it (even though “HTTP/1.1 conforming servers are required to support pipelining”). You can turn it on in Firefox in about:config and see if it works well.

As for minification (eliminating whitespace and comments and such), it does indeed help, even when combined with compression. One of my clients has an 80KiB front page, 40KiB of which is nothing but whitespace! They gzip the 80 down to 12, but gzipping the minified version gets you down to 9.7 — a significant savings when you get lots of hits per day. :)

There are free tools for minification, and they could be built into filters, and probably have been.

Sorry to babble on — this is one of my favorite topics because it unites security, usability, and performance and shows that the three work together, rather than opposing each other.

]]> By: Nate Lawson http://rdist.root.org/2009/03/09/ssl-is-not-table-salt/#comment-4920 Nate Lawson Tue, 10 Mar 2009 16:22:21 +0000 http://rdist.root.org/?p=292#comment-4920 Heh, thanks Chris. You're right that sesssion resumption and pipelining help significantly. I briefly looked at Wordpress and it appears to load many small images from a lot of different servers with no pipelining. Yahoo email goes through two separate SSL connections before getting the cookie and connecting to the email server (a third name lookup). On a related note, I've always wondered why there wasn't an html-compress filter that static content was run through as part of an install step. I'm not talking gzip, I mean things like removing all whitespace, reducing all javascript variables and functions to short versions, and eliminating comments. This plus gzip compression could greatly reduce load times, even without SSL. Of course, you wouldn't use this on the debugging server. Heh, thanks Chris. You’re right that sesssion resumption and pipelining help significantly. I briefly looked at WordPress and it appears to load many small images from a lot of different servers with no pipelining. Yahoo email goes through two separate SSL connections before getting the cookie and connecting to the email server (a third name lookup).

On a related note, I’ve always wondered why there wasn’t an html-compress filter that static content was run through as part of an install step. I’m not talking gzip, I mean things like removing all whitespace, reducing all javascript variables and functions to short versions, and eliminating comments. This plus gzip compression could greatly reduce load times, even without SSL. Of course, you wouldn’t use this on the debugging server.

]]> By: Chris Palmer http://rdist.root.org/2009/03/09/ssl-is-not-table-salt/#comment-4919 Chris Palmer Mon, 09 Mar 2009 21:19:17 +0000 http://rdist.root.org/?p=292#comment-4919 Preach it! As you know better than me, the symmetric and asymmetric encryption gets cheaper every year, is amortizable (HTTP 1.1 keep-alive, TLS session resumption), is acceleratable, and is a reasonable cost of doing business anyway. The tougher cost is the TLS handshake: there's no avoiding the network latency it incurs. Of course, that latency is also amortizable, AND, the majority of sites I've looked at are paying far worse costs than a little 100ms set-up. Sending 300KB of HTML/JS/CSS where 30KB would have the exact same meaning to the browser? Loading 40 images from 14 hostnames? Suboptimal JPEG compression level? An unoptimized AJAX client-side component? Failing to tell user agents and proxies to cache things properly? All those things cost considerably more (1 or more orders of magnitude) than the TLS handshake, yet they are the norm even on big, high-traffic web sites. I'm doing a talk on this topic at Web 2.0 Expo (April 2009) on this topic, to try to change the prevailing attitude. At the same time, maybe we can convince browser vendors to try HTTPS before HTTP when users type in "wellsfargo.com". :) Preach it! As you know better than me, the symmetric and asymmetric encryption gets cheaper every year, is amortizable (HTTP 1.1 keep-alive, TLS session resumption), is acceleratable, and is a reasonable cost of doing business anyway. The tougher cost is the TLS handshake: there’s no avoiding the network latency it incurs. Of course, that latency is also amortizable, AND, the majority of sites I’ve looked at are paying far worse costs than a little 100ms set-up. Sending 300KB of HTML/JS/CSS where 30KB would have the exact same meaning to the browser? Loading 40 images from 14 hostnames? Suboptimal JPEG compression level? An unoptimized AJAX client-side component? Failing to tell user agents and proxies to cache things properly? All those things cost considerably more (1 or more orders of magnitude) than the TLS handshake, yet they are the norm even on big, high-traffic web sites.

I’m doing a talk on this topic at Web 2.0 Expo (April 2009) on this topic, to try to change the prevailing attitude. At the same time, maybe we can convince browser vendors to try HTTPS before HTTP when users type in “wellsfargo.com”. :)

]]>