Dean Povey <povey(_at_)dstc(_dot_)qut(_dot_)edu(_dot_)au> writes:
SSL/TLS has built in compression support as part of the protocol, but this
has been slow to come to market. Why? One of the reasons has been that
you want to turn compression on and off depending on the underlying content
(e.g. if it is a GIF or JPG or .gz etc, don't compress).
zlib already does this transparently, it won't try to compress uncompressible
data (try running zip on a mixture of text and (say) other zip files, when it
says "Storing (0%)" it's generally zlib making the decision for you). For
SSL it's rather different because you've got an arbitrary stream of who
knows what rather than individual files like zip or CMS.
I think the real reason compression in SSL is been slow to come to market (and
the reason it will probably never be supported even though it's defined in the
spec, and OpenSSL nee SSLeay has supported it for some time) is because the
original implementations (Netscape/SSLref and later MS) never bothered
implementing it, and since it wasn't in there from the start noone else has
been able to get it in. In contrast ssh has has compression built in from the
start, as a result of which every single other implementation also has it, and
everyone uses it.
I think this supports my earlier argument that you need to add something like
this to a new(-ish) protocol, because it's never going to be retrofitted to
anything with an installed base (eg MIME). SSL vs ssh compression (and also
PGP vs S/MIME, which I'd already mentioned) only proves this point.
Peter.