Hi Joel, I filed a bug to track this: http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6421.
> > I was able to disable the use of weak and NULL cipher suites > by building a > custom modified cog-jglobus.jar library, using a copy of the > jglobus source > code acquired via anonymous CVS. The attached patch file shows > modifications I made to GlobusGSSContextImpl.java. > > After the new cog-jglobus.jar was deployed (to Tomcat, in my case), a > security scan no longer reported the use of weak and NULL > cipher suites, > which indicated this modification did have the desired effect > of disabling > weak encryption. > > However, further testing revealed that, in some cases, client > code that used > The "old" cog-jglobus.jar was unable to connect with a > service that used my > "new" cog-jglobus.jar. Replacing the "old" cog-jglobus.jar > on the client > side with my "new" version resolved the connectivity problem. > But this > unexpected break in backward compatibility called for closer > examination of > the code. I would expect this, because of the forced NULL ciphers in old jar. With your modification, there ceases to be any ciphers in common with new CoG jar based server and old CoG jar based client. I might use your patch and for an option of server allowing backwards compatiblity mode for old clients. > > The GlobusGSSContextImpl.java code obtained from CVS always > includes a NULL > cipher suite in the SSL policy. I think this is questionable > because, for > example, a client might be able to force the use of a NULL > cipher (i.e. > unencrypted connection), even if the service is configured > for privacy via > GSITransport. This observation is true at handshake level, but at GT WS Services level, the services configure security policy on required level of protection and post handshake the application invocation will fail. But I agree that this needs to be fixed such that the server required a configured set of ciphers. BTW, the latest CoG JGlobus releases are linked off http://dev.globus.org/wiki/CoG_jglobus (the recent releases also have the same behavior you observed). It also includes information on a CoG JGlobus mailing list where any bug updates will be sent. You can also add yourself to the bug to track changes. Rachana > > The GlobusGSSContextImpl.java code from CVS has another questionable > feature, in that, under some circumstances, the only cipher > suite it allows > is a NULL one. This would cause the connection to fail if > the other side > does not allow the NULL cipher suite (as in my "new" cog-jglobus.jar). > > The use of NULL cipher suites in GlobusGSSContextImpl.java seems very > strange to me, especially with regard to the concept of privacy via > GSITransport. Right now, I can't think of any reason I would > ever want to > use a NULL cipher suite on my secure web service. Am I > missing something > here? Could this be considered a bug (or bugs)? > > Other notes: > > - jglobus code was acquired via anonymous CVS, as illustrated > on the COG > JGlobus 1.2 page: http://dev.globus.org/wiki/CoG_JGlobus_1.2 > - There was no CVS tag for globus_4_0_8, so I used the most > recent code > from the globus_4_0_branch, as of September 24, 2008 > > Best regards, > Joel >
