On Tue, May 24, 2011 at 07:45:34PM -0600, Guan Jun He wrote: > > > >>> ? 10:23 ?? ? 5/24/2011 ????? > <[email protected]> ??Thor Lancelot Simon <[email protected]> > ???> On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: > >> Hi, > >> > >> This is a patch to add a switch to openssl's compression > >> methords(if compression methords are configured to compile in, 'config > >> zlib').Add an environment variable to control compression methords on > >> and off.As you know,more and more architectures have hardware > >> compression methords already, to get benifit from the hardware > >> compression, and to get a good performance,we need a switch as this. > > > > I don't understand this. Are you suggesting that some hardware mechanism > > is trying to compress data _after_ OpenSSL handles it? Turning off > > compression in OpenSSL won't help with this, since the resulting SSL/TLS > > stream will stil be basically uncompressible. > > > > I mean OpenSSL compresses data before the encryption(zlib compiled > in), having a massive performance impact (throughput decrease, CPU load > increase) on platforms with cryptographic hardware.
It seems to me you've said two differnt things, and I don't know which you mean. Do you mean "on platforms with hardware compression methods" or "on platforms with cryptographic hardware"? Or do you have a platform with both features, and a version of OpenSSL modified to take advantage of the platform's hardware cryptographic features, but not the platform's hardware compression features? I was in that situation for some time. I personally think that compression in OpenSSL needs to be made a first-class transform such that it can be handed off to engines. Though of course the engine interface needs other enhancements to deal with platforms that can do "fused" transforms like compress-then-encrypt-then-MAC, or full-on SSL record handling. But it would be a start. I think it should also be the case that compression (or not) should be selectable via the existing interface for setting options on the SSL_CTX. That would provide a more elegant way of dealing with the issue you're seeing (which I assume is triggered by an increased number of peers who want to do compression at the SSL layer because of the support for this in Chrome and in Google's server software) rather than an environent variable work-around. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
