geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Date Fri, 02 Sep 2005 11:57:12 GMT
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
>>
>>
>


Mime
View raw message