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

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-

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.

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-

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

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

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-