httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Thoughts on Camillia in openssl binaries?
Date Tue, 18 Sep 2007 20:45:51 GMT
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.

Mime
View raw message