Update Log

December 1, 2015 2:00pm CDT: First version


Globus is planning to change the default client-side algorithm for checking the server’s identity used by GridFTP, MyProxy, GSI-OpenSSH, and GRAM. The new algorithm performs identity matching as described in section 3.1 of RFC 2818, the standard describing TLS use with HTTP. This involves a change in the globus-gssapi-gsi library, and will apply to any application that uses the updated library.

The new “strict mode” algorithm will be more strict in its enforcement, checking that the server’s certificate identity matches the hostname that the client uses to contact the service. Once clients are configured for strict mode, client authentication (of any Globus service) would fail if the service is using a certificate that does not match the hostname that the client used to contact the service.

This change will bring our identity checking algorithm in line with RFC 2818, and will also close the door to reverse DNS lookup related attack vectors. As an example of why relying on reverse DNS for making security related decisions is not recommended, see this link: https://cwe.mitre.org/data/definitions/350.html.

The Globus team has checked the host certificates used for a number of GridFTP endpoints and found that many are not RFC 2818 compatible. These incompatible certificates will need to be replaced prior to clients defaulting to the new strict mode algorithm.

We are reaching out to request that Globus service admins check their host certificates and update them if necessary. We are asking admins to replace any incompatible certificates by March 1, 2016. After March 1, we will release updated Globus Toolkit components that will change the default client authorization algorithm to strict mode. At that time, the Globus.org transfer service will also update its' identity checking algorithm. This should ensure no service disruptions for the Globus community.

Note:Globus Connect Server installations that use the Globus provided certificate are not affected and do not have to make any changes to their Globus Connect Server endpoint(s).

If you have any questions or concerns regarding this planned change, please contact us at support@globus.org.

Common reasons for incompatibility:

  1. A host with multiple dns names, and the certificate identity matches some, but not all of them. For example, DNS name ep.example.org resolves to 10.0.0.1, which is the IP address of our server. Clients are connecting to the server by the ep.example.org DNS name. The cert on this server is for hostname host.example.org. Today, the reverse DNS lookup for 10.0.0.1 resolves to host.example.org this will work. The reason this works today is because the current algorithm resolves the hostname the client uses to connect to an IP address, then does a reverse DNS lookup on that IP to see if there is a match for the name in the cert. However, the new strict mode algorithm will use the original hostname the client uses to connect to the server only.

    Fix:

    1. Get a new host certificate with a DN that matches the DNS name that clients use to connect to the server.

      Note:in RFC 2818 subjectAltName(s) take precedence over CN entries (see note below)
    2. Get a new host certificate with a subjectAltName dnsName extension field that matches the DNS name that clients use to connect to the server.

    3. Getting a host certificate with multiple subjectAltName dnsName extension fields, one for each hostname, is necessary if more than a single hostname will be used by users to access the server.

  2. Multiple hosts with IP addresses that resolve to similar hostnames (host-1.example.org, host-2.example.org, etc), acting as a single service (GridFTP, GSISSH, MyProxy, GRAM, …). In that case the old algorithm would treat the -1, -2 hostname suffixes as wildcards and ignore them for name comparisons. This is no longer the case with the new algorithm.

    Fix:

    1. If the different names are implemented as multiple IP addresses for a common name "host.example.org", then get a certificate for that common name and put it on all servers.

      Note:in RFC 2818 subjectAltName(s) take precedence over CN entries (see note below)
    2. Get a new certificate with a subjectAltName dnsName extension field using a wildcard (host*.example.org) that will match all hostnames.

    3. Get a certificate with multiple subjectAltName entries, one for each hostname used.

      Note:Many IGTF CAs do not support wildcard certificates. Also many IGTF CAs do not support multiple subjectAltName entries, but we expect many CAs to add support for it soon.

How to check for compatibility

In order to check that your new configuration will work with the new algorithm, you can use the one of the following methods:

Using grid-cert-diagnostics

To check a GridFTP server:

# export GLOBUS_GSSAPI_NAME_COMPATIBILITY=STRICT_RFC2818
# grid-cert-diagnostics -g gridftphostname:port

To check a MyProxy or GRAM server:

# export GLOBUS_GSSAPI_NAME_COMPATIBILITY=STRICT_RFC2818
# grid-cert-diagnostics -s servicehostname:port

To check a GSI-OpenSSH server:

# export GLOBUS_GSSAPI_NAME_COMPATIBILITY=STRICT_RFC2818
# grid-cert-diagnostics -c /etc/grid-security/hostcert.pem
Note:replace path above if not in the typical location.

For a successful test, you should see the following relevant line in the output:

Performing name comparison... ok

If the test failed, you’ll see the following relevant line in the output:

Performing name comparison... not ok

If you don’t have grid-cert-diagnostics installed, it is in the "globus-proxy-utils” package available for download from http://toolkit.globus.org/toolkit/downloads/6.0/. (Note: only the "globus-proxy-utils” package in the GT6 repo has the required version of the grid-cert-diagnostics program.)

If you have grid-cert-diagnostics installed, but the -g/-s option is not recognized, then update to the latest version of the "globus-proxy-utils” package from the GT6 repo.

Using openssl

An alternative option to inspect a host certificate used by any service:

First check the CN of the subject DN:

# openssl x509 -subject -noout -in hostcert.pem

subject= /DC=com/DC=DigiCert-Grid/O=Open Science
Grid/OU=Services/CN=cli.globusonline.org

If the CN matches the DNS name that clients use to connect to your server, then your cert will work. Note: in RFC 2818 subjectAltName(s) take precedence over CN entries (see note below)

Also check the Subject Alt Name extension fields (if present) to see if any of the entries here are for a DNS name that matches the DNS name that clients use to connect to your service:

# openssl x509 -text -noout -in hostcert.pem | grep -A1 "X509v3 Subject Alternative Name:"

            X509v3 Subject Alternative Name:
                DNS:cli.globusonline.org

If any of these entries match the DNS name that clients use to connect to your service, then your cert will work.

Note:If your cert contains any Subject Alt Name extension fields, then at least one of these MUST match the DNS name that clients use to connect to your service. This is true even if the CN of your subject DN matches the DNS name that clients use to connect. The reason for this is that RFC 2818 specifies that the Subject Alt Name extension (if present) MUST be used to establish identity.