Bug 3036 - support TLSv1 in GSI GSSAPI library
: support TLSv1 in GSI GSSAPI library
: 3.9.5
: All All
: P3 enhancement
: 4.0.2
Assigned To:
: 4.0.x, VDT
: 6192
  Show dependency treegraph
Reported: 2005-03-30 12:54 by
Modified: 2008-08-15 05:37 (History)

proposed patch to add TLSv1 support to GSI GSSAPI library (3.24 KB, patch)
2005-03-30 12:56, Jim Basney
proposed patch to force TLSv1 if $GLOBUS_GSSAPI_FORCE_TLS defined (3.10 KB, patch)
2005-05-10 13:53, Jim Basney


You need to log in before you can comment on or make changes to this bug.

Description From 2005-03-30 12:54:19
The GSI GSSAPI library currently forces use of SSLv3 for both initiator and
accepter with

  SSL_set_ssl_method(context->gss_ssl, SSLv3_method());

Unfortunately, if we simply try to add TLSv1 support by changing this call to

  SSL_set_ssl_method(context->gss_ssl, SSLv23_method());

then we have a backward compatibility problem.  If the initiator uses
SSLv23_method() and the accepter 
uses SSLv3_method(), the accepter will fail with "OpenSSL Error: s3_pkt.c:297:
in library: SSL routines, 
function SSL3_GET_RECORD: wrong version number".  There's some issue that I
don't understand with 
falling back to SSLv3 in this case, so we'd have a problem with currently
deployed accepters if we made 
this simple change.

I've done my best to address this in the following patch.  By default,
accepters will accept SSLv3 or 
TLSv1 (i.e., use SSLv23_method()), but initiators will only try SSv3 (i.e., use
SSLv3_method()), so as not 
to crash older accepters.  However, if GLOBUS_GSSAPI_FORCE_TLS is defined in
the environment, then 
initiators will only try TLSv1, and accepters will only accept TLSv1.  Thus, we
have the following cases:

   initiator       accepter       result
   old               old               SSLv3
   old               new              SSLv3
   old               FORCE_TLS   fail
   new              old               SSLv3
   new              new              SSLv3
   new              FORCE_TLS   fail
   FORCE_TLS   old                fail
   FORCE_TLS   new              TLSv1

It's a little bit messy, but at least it gets us moving toward TLSv1 support,
and eventually, when all old 
accepters are updated, we can move to doing SSLv23_method() by default on both
------- Comment #1 From 2005-03-30 12:56:18 -------
Created an attachment (id=556) [details]
proposed patch to add TLSv1 support to GSI GSSAPI library
------- Comment #2 From 2005-04-04 21:04:04 -------
One of the problems with this patch is that a lot of code uses GSS_C_BOTH, so
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.

------- Comment #3 From 2005-05-04 17:31:19 -------
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.
------- Comment #4 From 2005-05-10 13:53:29 -------
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.
------- Comment #5 From 2005-05-10 16:04:46 -------
(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)

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.
------- Comment #6 From 2005-05-10 18:29:12 -------
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.

------- Comment #7 From 2005-05-10 18:48:49 -------
committed patch to cvs head
------- Comment #8 From 2005-05-11 19:55:29 -------
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]
------- Comment #9 From 2007-08-30 06:29:26 -------
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
------- Comment #10 From 2008-08-15 05:37:50 -------
Merged to 4.0 branch as well now.