Geir Magnusson Jr. wrote:
I was talking to Alan and mentioned this. He had another suggestion
- lets just (for now) get the ASN1 code from BC and package it
ourselves. Coupled with the suggestion about removing the IDEA
algorithm as a possibility, we remove the dep on BC in OpenEJB.
I took a crack at stripping down the BC package to just the ASN1 code.
There are two classes that pull in digest code, which pulls in much of
the crypto engine. Thankfully, Geronimo does not depend on those two
classes, and there are no direct references to those classes in the rest
of the ASN1 code, so they can be deleted. Once that is done, it is a
pretty manageable dependency chain, and the code builds just fine. The
resulting package has support for many more datatypes than Geronimo
requires, but I'm not sure a full pruning effort would be justified.
Then, we don't ship BC w/ geronimo, but let the console detect if BC
is present and then show a message and warning where appropriate
where to get the jar and how to install if not.
I suggest we also take the step of removing the IDEA algorithms from the
SSL cipher suite list, otherwise the exposure scenario I outlined still
exists. The download of the bouncycastle code changes the behavior of
the SSL support without the Geronimo users having any control over the
matter. Removing those algorithms from the list removes that exposure.
Then Geronimo is clean, the functionality is optional, and users have
no risk of encountering a problem, unless they can't read.
geir
On Sep 1, 2005, at 1:36 PM, Rick McGuire wrote:
I found an interesting example of the inadverent problems that can
be caused by Geronimo's current usage of bouncycastle. The openejb
SunOrb codes specifies a list of supported cipher suites to be used
with SSL connections in the class SSLCipherSuiteDatabase. The
supported list includes the IDEA algorithms. The Sun default JCE
implemenation does not include IDEA, so this will not be used unless
additional JCE provides are installed which include IDEA support.
So far, so good. The IDEA code, even though listed as an option,
will not get used without explicit knowledge of the Gernonmo
administrator.
However, the current console code uses the bouncycastle code to
implement its keystore. This usage is in a manner that requires the
BC provider code to be installed programmatically, which the console
code does. Unfortunately, once this is done, the IDEA algorithms
are now available for use for SSL connections as well. This server
is now potentially a royalty collection target by the IDEA patent
holders, since they can demonstrate usage by having a client connect
with this server using the IDEA ciphers. We might even want to
consider allowing these algorithms to be controlled by the server
config rather than just hard coding them in the class.
One way to fix this is just remove the IDEA algorithms from the
SSLCipherSuiteDatabase, so these will not be used for SSL
connections. Another potential solution (yet to be verified) is to
use the BC APIs that allow the default JCE provider to be used for
encryption services rather than defaulting to the BC provider.
Rick
