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-
