pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
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.
My reading of the TLS/SSL compression situation is rather
different.
First, neither SSL nor TLS in fact defines compression.
Rather, they define a slot in which compression could be
fitted if one were to define it. No specific algorithm is
defined.
My interpretation of the history is that compression support
foundered on intellectual property issues. I.e. there was no
algorithm which everyone could agree was unencumbered. Since
there was a desire to get the spec out quickly and the issue
was sticky, it was punted. I definitely remember several
meetings of the IPSEC working group where the IP situation
was discussed and it was distinctly murky.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]
PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/