If you're interested in compression information relating to SSL/TLS, I'd also suggest asking on the openssl-dev list. As of openssl 0.9.8, zlib compression is used by default if the library is built with it; however, it has also caused some issues with SSL compatibility (leading to "invalid HMAC" alerts/connection drops).
-Kyle H On 2/9/06, Nelson B <[EMAIL PROTECTED]> wrote: > Steve Parkinson wrote: > > >> I understand there is a compression-negotiation feature in the SSL > >> protocol. > > Yes, and there are some RFCs about it. > http://www.rfc-editor.org/rfc/rfc3749.txt > http://www.rfc-editor.org/rfc/rfc3943.txt > > >> But, it seems implementation of compression schemes for this is pretty > >> rare. Is there a technical reason why? > > I cannot speak for the whole industry, but I can tell you historically > why compression support is not yet found in NSS-based server products. > > When I started working on SSL at Netscape in 1997, one of my first > projects was to explore the use of compression in SSL3. Encryption > was known to defeat the compression built into most modems, and the > hope was that compressing before encryption would compensate for that. > > But there was a big performance concern. It was well known that https > servers got much lower throughput than http servers for the same sorts > of traffic on the same hardware, largely due to the costs of CPU-based > encryption. The server market was very sensitive to price/performance, > and the server products didn't want a feature that would further reduce > the throughput associated with SSL. It was feared that the added CPU > cycle cost of compression would further reduce server throughput. > > On the other hand, it was hoped that compression would reduce the amount > of text that needed to be encrypted enough that the sum of the added > compression cost plus the reduced encryption cost would be a net > reduction in the CPU cost of sending an encrypted SSL record. > > At that time, the best known compression algorithms were patented. > (Perhaps they still are.) Netscape had licensed a very fast compression > library from the patent holder, and my job was to evaluate its effect on > throughput and performance of SSL. > > To make a long story short, the result was that time cost of compression > plus encryption was at best (that is, at least) 50% more than the cost of > encryption alone, and often 100% more. The message I got was that the > server product teams were completely uninterested in a feature that > would have such an effect on performance. So, it was dropped, and never > found its was into HCL, the predecessor of NSS. Had it succeeded, it > would have been my first opportunity to write an RFC. > > 7 years later, interest in compression was resurrected in the IETF-TLS > working group, resulting in the publication of the above cited RFCs. > Yet, despite their existence, we observe that it is still not widespread. > Perhaps this has something to do with the patent status of the compression > algorithms, or perhaps the performance issue is the same as before. > > >> Steve Parkinson > >> Red Hat > > Regards, > -- > Nelson B > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
