Bugzilla – Bug 3036
support TLSv1 in GSI GSSAPI library
Last modified: 2008-08-15 05:37:50
You need to
before you can comment on or make changes to this bug.
The GSI GSSAPI library currently forces use of SSLv3 for both initiator and
Unfortunately, if we simply try to add TLSv1 support by changing this call to
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
FORCE_TLS FORCE_TLS 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
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
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.
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)
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.
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]
the bug seems to be still unfixed in 4.0.3 (in VDT-1.6.0 distribution),
please commit it to 4.0 too.
Merged to 4.0 branch as well now.