[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-dev
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=EF=BC=9A=20Re:=20=3F=3F=3F=20Re:=20?=
From: "Guan Jun He" <gjhe () novell ! com>
Date: 2011-05-26 7:59:29
Message-ID: 4DDE78E1020000160000771D () novprvlin0050 ! provo ! novell ! com
[Download RAW message or body]
>>> 在 11:15 下午 的 5/25/2011 上,在讯息
<20110525151556.GA5092@panix.com> 中,Thor Lancelot Simon <tls@panix.com>
写入:> On Tue, May 24, 2011 at 07:45:34PM -0600, Guan Jun He wrote:
>>
>>
>> >>> ? 10:23 ?? ? 5/24/2011 ?????
>> <20110524142324.GA29838@panix.com> ??Thor Lancelot Simon <tls@panix.com>
>> ???> 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.
Yes, I mean this.Have you made any progress on this?
Before the engine's enhancements, we probably should also provide users a way to work-around it.
For platforms with both features, there is really a performance reduction.
Till now, I can think of two methords to work-around it:
*#1* environment variable (easiest way)
*#2* add an item to configure file openssl.cnf (no essential difference from methord #1)
Do you agree this?
or what do you think about this?
Thanks!
>
> 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.
This is a good idea, make it negotiate-able in SSL session.and the work-around
environent variable can also work with it together, and provide users a control to
use the compression or not.After the engine is enhanced, we can easily disable
the environment variable or remove it.
best,
Guanjun
>
> Thor
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majordomo@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic