You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/09/18 17:21:00 UTC
Thoughts on Camillia in openssl binaries?
Two questions, one technical one legal.
Technically, do we want to enable the Camillia algorithms in our
binary builds of openssl 0.9.8 for win32 and other platforms where
we might build it?
Legally are we satisfied by
http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
? There is a small clause about permission needed to export from
JP, which would mean if a JP site redistributed our binary (e.g.
reexported it) it might cause them a hassle.
Bill
Re: OpenSSL compression (Windows)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tom Donovan wrote:
>
> A case can be made for not enabling OpenSSL compression on Windows.
>
> If both parties to an SSL connection support compression, it is used for
> everything on the connection without regard to whether the content is
> compressible.
>
> Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and
> any content filtered by mod_deflate are re-compressed. This uses
> non-trivial CPU cycles for no (or slightly negative) benefit.
>
> Testing with some current browsers (FireFox 2.0.0.7, IE 6.0.2800.1106,
> IE 7.0.6000.16512, Opera 9.23) shows that none support TLS compression,
> even though they all have gzip capability - so there is not currently
> any issue with browser requests.
Agreed, I think we need to get a handle on this within mod_ssl itself.
> The problem is when Apache is configured to proxy via https to another
> Apache server. If both servers have OpenSSL compression enabled,
> everything will be compressed (or re-compressed). If both OpenSSL
> libraries support compression, there is no apparent way to override this
> behavior. Previously, deleting zlib1.dll would accomplish this - but
> now deleting zlib1.dll will disable mod_deflate as well.
Not on win32, all the binaries I've created are --enable-zlib, never
--enable-zlib-dynamic. On 0.9.7 this was all irrelevant of course.
> Since mod_deflate can be tailored to compress appropriate content per
> request, the need to have compression at the connection level seems to
> be an unusual one. Perhaps those few folks who do want this could
> rebuild OpenSSL with compression enabled rather than shipping OpenSSL
> with it enabled.
Keep in mind w.r.t. the win32 distribution, we need it enabled to
support compression of ajp streams, ftp data streams etc.
You are right about missing the context of compressibility, it would be
very nice if after packing up 64k and realizing little or no benefit,
if openssl would back off and decide to ship off the contents without
compression. Because the feature is
I agree for https that mod_deflate works out better than built in
compression, so perhaps on a protocol level, beyond SSL Enable, we
need some 'SSL Enable nodeflate' sort of choice that can be dropped
into an https vhost, leaving it enabled, for example on an FTP Implicit
SSL vhost.
Bill
Re: OpenSSL compression (Windows)
Posted by Henrik Nordstrom <he...@henriknordstrom.net>.
On fre, 2007-09-21 at 11:06 -0400, Tom Donovan wrote:
> Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and
> any content filtered by mod_deflate are re-compressed. This uses
> non-trivial CPU cycles for no (or slightly negative) benefit.
Bot yes and no. Unlike HTTP, SSL compression applies to the whole
datastream including request & response headers, not only the object
body. So exchanges of small objects over a persistent connection is
likely to compress quite well even if the exchanged object as such is
already fully compressed.
But it may be a problem for large exchanges, or when KeepAlive is off..
Regards
Henrik
OpenSSL compression (Windows)
Posted by Tom Donovan <do...@bellatlantic.net>.
New topic - was "Thoughts on Camillia in openssl binaries?"
William A. Rowe, Jr. wrote:
> Tom Donovan wrote:
>> William A. Rowe, Jr. wrote:
>>> Two questions, one technical one legal.
>
>> On a slightly-related note; it might also be a good change to statically
>> link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds
>> about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll.
>
> Are you factoring in the cost of statically linking it also to mod_deflate?
> Consider also anyone using either the compression or decompression side of
> zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment
> of awk.exe for the installer that I'm pretty intolerant of bloat,
>
>> I think rle compression (which is always available) or no-compression
>> gets used for SSL in most cases anyway. Many Windows users delete
>> zlib1.dll and never notice its absence.
>
> Well people who randomly delete dll's certainly get what they ask for,
> we install it in the httpd/bin tree, not on their system32 or somewhere
> equally offensive.
>
> But if mod_deflate doesn't use it, and openssl is built zlib-dynamic,
> they simply pitched compression from ssl sessions as well with no other
> adverse effects.
>
>> PERL Configure VC-WIN32 enable-camellia zlib
>> --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib
>
> FYI the ASF's build hard-links it this way (zdll.lib instead) which
> ensures we throw away the zlib-dynamic stubs (and eliminate some race
> and processing-time performance hits), so there is that factor, too.
>
> I sort of doubt we'll see any savings when you factor deflate and openssl
> together?
>
> The other aspect, if a zlib1.dll replacement is needed for some critical
> decryption flaw in zlib again, it will be nice not to force users to
> entirely replace openssl or mod_deflate. So I expect we'll leave it
> as-is.
>
A case can be made for not enabling OpenSSL compression on Windows.
If both parties to an SSL connection support compression, it is used for
everything on the connection without regard to whether the content is
compressible.
Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and
any content filtered by mod_deflate are re-compressed. This uses
non-trivial CPU cycles for no (or slightly negative) benefit.
Testing with some current browsers (FireFox 2.0.0.7, IE 6.0.2800.1106,
IE 7.0.6000.16512, Opera 9.23) shows that none support TLS compression,
even though they all have gzip capability - so there is not currently
any issue with browser requests.
The problem is when Apache is configured to proxy via https to another
Apache server. If both servers have OpenSSL compression enabled,
everything will be compressed (or re-compressed). If both OpenSSL
libraries support compression, there is no apparent way to override this
behavior. Previously, deleting zlib1.dll would accomplish this - but
now deleting zlib1.dll will disable mod_deflate as well.
Since mod_deflate can be tailored to compress appropriate content per
request, the need to have compression at the connection level seems to
be an unusual one. Perhaps those few folks who do want this could
rebuild OpenSSL with compression enabled rather than shipping OpenSSL
with it enabled.
Something to consider for future releases.
-tom-
Re: Thoughts on Camillia in openssl binaries?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tom Donovan wrote:
> William A. Rowe, Jr. wrote:
>>
>> The other aspect, if a zlib1.dll replacement is needed for some critical
>> decryption flaw in zlib again, it will be nice not to force users to
>> entirely replace openssl or mod_deflate. So I expect we'll leave it
>> as-is.
>>
> I think mod_deflate on Windows links statically (zlib.lib) while openssl
> is linked dynamically (zdll.lib). At 40-60kb it's no big deal either
> way - but the "security flaw in zlib" argument would seem to apply to
> both equally. Both static or both dynamic would be more consistent.
This was 2.0 that compiled in the subset of zlib sources directly.
2.2 should (and I'll fix this if I'm wrong) be linked to zlib1.dll
Re: Thoughts on Camillia in openssl binaries?
Posted by Jorge Schrauwen <jo...@gmail.com>.
Very interesting I'll keep and eye out for 5.10...
Now back on topic...
On 9/20/07, Steve Hay <St...@planit.com> wrote:
>
> Perl 5.9.5 contains numerous changes to support building with MSVC80.
> These changes will be in 5.8.9 when that gets released, but 5.10 is
> looking distinctly likely to be released before it (and, of course, will
> also contain the changes).
>
> Steve
>
> ------------------------------
> *From:* Jorge Schrauwen [mailto:jorge.schrauwen@gmail.com]
> *Sent:* 20 September 2007 09:37
> *To:* dev@httpd.apache.org
> *Subject:* Re: Thoughts on Camillia in openssl binaries?
> I found ActivePerl to not work to well on x64... I compiled the original
> perl source with MSVC70 and it works ok with extensions compiled with
> MSVC80... I never manged to get perl itself on MSVC80. I had no luck with
> ActiveState Perl.
>
> --
> > ~Jorge
>
>
--
~Jorge
RE: Thoughts on Camillia in openssl binaries?
Posted by Steve Hay <St...@planit.com>.
Perl 5.9.5 contains numerous changes to support building with MSVC80.
These changes will be in 5.8.9 when that gets released, but 5.10 is
looking distinctly likely to be released before it (and, of course, will
also contain the changes).
Steve
________________________________
From: Jorge Schrauwen [mailto:jorge.schrauwen@gmail.com]
Sent: 20 September 2007 09:37
To: dev@httpd.apache.org
Subject: Re: Thoughts on Camillia in openssl binaries?
I found ActivePerl to not work to well on x64... I compiled the original
perl source with MSVC70 and it works ok with extensions compiled with
MSVC80... I never manged to get perl itself on MSVC80. I had no luck
with ActiveState Perl.
--
~Jorge
Re: Thoughts on Camillia in openssl binaries?
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/20/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Tom Donovan wrote:
> > William A. Rowe, Jr. wrote:
> >>
> >> But if mod_deflate doesn't use it, and openssl is built zlib-dynamic,
> >> they simply pitched compression from ssl sessions as well with no other
> >> adverse effects.
> > Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic
> > and zlib1.dll is missing.
> >>
> >> The other aspect, if a zlib1.dll replacement is needed for some
> critical
> >> decryption flaw in zlib again, it will be nice not to force users to
> >> entirely replace openssl or mod_deflate. So I expect we'll leave it
> >> as-is.
> >>
> > I think mod_deflate on Windows links statically (zlib.lib) while openssl
> > is linked dynamically (zdll.lib). At 40-60kb it's no big deal either
> > way - but the "security flaw in zlib" argument would seem to apply to
> > both equally. Both static or both dynamic would be more consistent.
>
> You were right, we weren't linking to zdll.lib for mod_deflate, I'll be
> fixing that shortly, and working up the two patches to share, one for the
> APR_NO_FILE tweak, one for the stderr quirk with modperl.
>
> Had to push out these binaries first, and also now am struggling very
> deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs
> that some of the perl packages have, assuming they can pack pointers
> into int's and back out again. Sorry that mess left me distracted from
> the issues you raised for most of this week.
I found ActivePerl to not work to well on x64... I compiled the original
perl source with MSVC70 and it works ok with extensions compiled with
MSVC80... I never manged to get perl itself on MSVC80. I had no luck with
ActiveState Perl.
Bill
>
--
~Jorge
Re: Thoughts on Camillia in openssl binaries?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tom Donovan wrote:
> William A. Rowe, Jr. wrote:
>>
>> But if mod_deflate doesn't use it, and openssl is built zlib-dynamic,
>> they simply pitched compression from ssl sessions as well with no other
>> adverse effects.
> Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic
> and zlib1.dll is missing.
>>
>> The other aspect, if a zlib1.dll replacement is needed for some critical
>> decryption flaw in zlib again, it will be nice not to force users to
>> entirely replace openssl or mod_deflate. So I expect we'll leave it
>> as-is.
>>
> I think mod_deflate on Windows links statically (zlib.lib) while openssl
> is linked dynamically (zdll.lib). At 40-60kb it's no big deal either
> way - but the "security flaw in zlib" argument would seem to apply to
> both equally. Both static or both dynamic would be more consistent.
You were right, we weren't linking to zdll.lib for mod_deflate, I'll be
fixing that shortly, and working up the two patches to share, one for the
APR_NO_FILE tweak, one for the stderr quirk with modperl.
Had to push out these binaries first, and also now am struggling very
deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs
that some of the perl packages have, assuming they can pack pointers
into int's and back out again. Sorry that mess left me distracted from
the issues you raised for most of this week.
Bill
Re: Thoughts on Camillia in openssl binaries?
Posted by Tom Donovan <do...@bellatlantic.net>.
William A. Rowe, Jr. wrote:
>
> But if mod_deflate doesn't use it, and openssl is built zlib-dynamic,
> they simply pitched compression from ssl sessions as well with no other
> adverse effects.
Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic
and zlib1.dll is missing.
>
> The other aspect, if a zlib1.dll replacement is needed for some critical
> decryption flaw in zlib again, it will be nice not to force users to
> entirely replace openssl or mod_deflate. So I expect we'll leave it
> as-is.
>
I think mod_deflate on Windows links statically (zlib.lib) while openssl
is linked dynamically (zdll.lib). At 40-60kb it's no big deal either
way - but the "security flaw in zlib" argument would seem to apply to
both equally. Both static or both dynamic would be more consistent.
-tom-
Re: Thoughts on Camillia in openssl binaries?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tom Donovan wrote:
> William A. Rowe, Jr. wrote:
>> Two questions, one technical one legal.
>>
>> Technically, do we want to enable the Camillia algorithms in our
>> binary builds of openssl 0.9.8 for win32 and other platforms where
>> we might build it?
>>
>> Legally are we satisfied by
>> http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
>> ? There is a small clause about permission needed to export from
>> JP, which would mean if a JP site redistributed our binary (e.g.
>> reexported it) it might cause them a hassle.
>>
>> Bill
>>
> Seems reasonable in anticipation of it becoming supported in FireFox 3.
Yes, that seems like a measurable target. It's nice to be ahead of the
curve.
> FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows
> to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia.
> The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA.
Good to know, thanks!
> On a slightly-related note; it might also be a good change to statically
> link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds
> about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll.
Are you factoring in the cost of statically linking it also to mod_deflate?
Consider also anyone using either the compression or decompression side of
zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment
of awk.exe for the installer that I'm pretty intolerant of bloat,
> I think rle compression (which is always available) or no-compression
> gets used for SSL in most cases anyway. Many Windows users delete
> zlib1.dll and never notice its absence.
Well people who randomly delete dll's certainly get what they ask for,
we install it in the httpd/bin tree, not on their system32 or somewhere
equally offensive.
But if mod_deflate doesn't use it, and openssl is built zlib-dynamic,
they simply pitched compression from ssl sessions as well with no other
adverse effects.
> PERL Configure VC-WIN32 enable-camellia zlib
> --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib
FYI the ASF's build hard-links it this way (zdll.lib instead) which
ensures we throw away the zlib-dynamic stubs (and eliminate some race
and processing-time performance hits), so there is that factor, too.
I sort of doubt we'll see any savings when you factor deflate and openssl
together?
The other aspect, if a zlib1.dll replacement is needed for some critical
decryption flaw in zlib again, it will be nice not to force users to
entirely replace openssl or mod_deflate. So I expect we'll leave it
as-is.
Re: Thoughts on Camillia in openssl binaries?
Posted by Tom Donovan <do...@bellatlantic.net>.
William A. Rowe, Jr. wrote:
> Two questions, one technical one legal.
>
> Technically, do we want to enable the Camillia algorithms in our
> binary builds of openssl 0.9.8 for win32 and other platforms where
> we might build it?
>
> Legally are we satisfied by
> http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
> ? There is a small clause about permission needed to export from
> JP, which would mean if a JP site redistributed our binary (e.g.
> reexported it) it might cause them a hassle.
>
> Bill
>
Seems reasonable in anticipation of it becoming supported in FireFox 3.
FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows
to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia.
The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA.
On a slightly-related note; it might also be a good change to statically
link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds
about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll.
I think rle compression (which is always available) or no-compression
gets used for SSL in most cases anyway. Many Windows users delete
zlib1.dll and never notice its absence.
PERL Configure VC-WIN32 enable-camellia zlib
--with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib
-tom-