Created an attachment (id=556) [details]
proposed patch to add TLSv1 support to GSI GSSAPI library

One of the problems with this patch is that a lot of code uses GSS_C_BOTH, so
in
addition to this path we would have to audit our current code base for
GSS_C_BOTH and change those usages to something more appropriate if the cert is
only used for accepting contexts.

/Sam

Our company has a Microsoft Windows based SSH product which supports the 
Globus Authentication method as one of its authentication methods.  We are 
currently in the process of making that application FIPS-140 compliant.  The 
FIPS-140 US and Canadian government standard requires the use of the TLSv1 
method.  Adding the ability to the server side Globus authentication logic to 
support TLSv1 will allow us to proceed with our project, and continue to 
support the Globus authentication method.

Created an attachment (id=604) [details]
proposed patch to force TLSv1 if $GLOBUS_GSSAPI_FORCE_TLS defined

This updated patch removes the problematic GSS_C_INITIATE case in the previous
patch and just adds the ability to force TLSv1 by setting
GLOBUS_GSSAPI_FORCE_TLS in the environment for both initiator and accepter.

(From update of attachment 556 [details])
Sam, you questioned the use of GSS_C_INITIATE in my first patch, but I
notice that globus_i_gsi_gss_create_and_fill_context() is already
using GSS_C_INITIATE in the same way:

    if ( cred_usage == GSS_C_INITIATE)
    {
	SSL_set_connect_state(context->gss_ssl);
    }
    else
    {
	SSL_set_accept_state(context->gss_ssl);
    }

So I have to disagree that this is a problem with the original patch.

Also, I've figured out the backward compatibility problem.  If
initiators use SSLv23_method(), they'll send an SSLv2 hello message,
which SSLv3_method() accepters won't understand.  Unfortunately, I
don't see a way to get OpenSSL to send an SSLv3 client hello message
indicating support for both TLSv1 and SSLv3, even though that's a
recommended option in RFC 2246 Appendix E.  So I still think the first
patch is the best option for moving forward on TLS support.

Yea, looking at it again I was thrown of by the fact the gaa_acquire_cred will
use GSS_C_BOTH when 
nothing is specified. I see now that we somewhat overload the GSS_C_INIT
constant during context 
creation, so I agree the initial patch looks fine. I'll apply it to trunk and
after 4.0.1 comes out I will apply it 
to the 4.0 branch.

/Sam

committed patch to cvs head

Good news passed along by Kenneth Robinette and Stephen Henson on
the OpenSSL SSLv2 client hello issue.  Looks like we'll have the
compatibility support I was looking for starting with OpenSSL
0.9.7h.  According to http://cvs.openssl.org/chngview?cn=13321:

  Changes between 0.9.7g and 0.9.7h  [XX xxx XXXX]
 
+  *) Change the client implementation for SSLv23_method() and
+     SSLv23_client_method() so that is uses the SSL 3.0/TLS 1.0
+     Client Hello message format if the SSL_OP_NO_SSLv2 option is set.
+     (Previously, the SSL 2.0 backwards compatible Client Hello
+     message format would be used even with SSL_OP_NO_SSLv2.)
+     [Bodo Moeller]

Hello,
the bug seems to be still unfixed in 4.0.3 (in VDT-1.6.0 distribution),
please commit it to 4.0 too.

Zdenek Salvet                                              
EGEEII/gLite developer

Merged to 4.0 branch as well now.