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
