> On May 5, 2016, at 10:59 AM, Cameron Harr <ch...@llnl.gov> wrote: > > Hi, > The instructions here say if you're using Globus-provided certs, you aren't > affected. Does that include simple-CA certs?
No. Globus-provided certs is referring to the certs included in the globus connect server package/setup. Those certs don't have a hostnames in them so they don't matter for strict name checking. Globus Transfer will always include the subject DN when connecting to a GCS endpoint configured with the included certificate. GCS (or any GridFTP server) will not do a DNS lookup if the subject DN is included from the client. > If so, are we still OK even if we see the "not ok" string at the end of > grid-cert-diagnostics? I'm seeing the following and want to know if I can > ignore this or not as it's Globus-provided: > Checking subjectAltName extensions... no > Verifying certificate chain... failed > globus_credential: Error verifying credential: Failed to verify credential > globus_gsi_callback_module: Could not verify credential > globus_gsi_callback_module: Error with signing policy > globus_gsi_callback_module: Error in OLD GAA code: The subject of the > certificate "/C=US/O=Globus Consortium/CN=Globus Connect CA" does not match > the signing policies defined in > /etc/grid-security/certificates/7a42187f.signing_policy > > Performing name comparison... not ok > > Thanks, > Cameron > > On 05/04/2016 07:25 AM, Stuart Martin wrote: >> The change will be in package: globus-gssapi-gsi with version greater than >> or equal to 12.0 >> >>> On May 4, 2016, at 9:07 AM, Steven C Timm < >>> <mailto:t...@fnal.gov>t...@fnal.gov <mailto:t...@fnal.gov>> wrote: >>> >>> What has not been clear to me is the following: >>> Stuart Martin's E-mail says that new clients will be released but it does >>> not say what Globus >>> version that those new clients correspond to. How do we tell via the >>> client versions which ones >>> are enforcing strict mode and which ones are not? Furthermore those of us >>> who get the globus clients through other distributions, how do we tell when >>> our distribution is starting to use them? >>> >>> Steve Timm >>> >>> >>> ________________________________________ >>> From: gt-user-boun...@lists.globus.org >>> <mailto:gt-user-boun...@lists.globus.org> <gt-user-boun...@lists.globus.org >>> <mailto:gt-user-boun...@lists.globus.org>> on behalf of Basney, Jim >>> <jbas...@illinois.edu <mailto:jbas...@illinois.edu>> >>> Sent: Wednesday, May 4, 2016 9:00:54 AM >>> To: GT User >>> Subject: Re: [gt-user] Globus ³strict mode² coming March 2016 - Action >>> Required >>> >>> Hi, >>> >>> Did this change happen as planned? Is the transition going OK for everyone? >>> >>> In my role as CA operator, I know we've been issuing a lot of host certs >>> with multiple subjectAltNames in preparation for this transition, so >>> hopefully everyone has the certs they need. >>> >>> -Jim >>> >>> On 2/4/16, 5:21 PM, Stuart Martin wrote: >>>> Hi All, >>>> >>>> Here is a reminder about this deadline and upcoming change. >>>> >>>> Admins should check their host certificates and update them if necessary. >>>> Replace any incompatible certificates by Mar 1, 2016. >>>> >>>> To allow a bit of a buffer between the service-side certificate update >>>> deadline and clients beginning to use strict mode, updates will be made >>>> to the Globus Toolkit to default the client-side algorithm to strict mode >>>> on Tuesday, April 5, 2016. >>>> >>>> - The Globus Team >>>> >>>>> On Dec 1, 2015, at 2:50 PM, Stuart Martin <smar...@mcs.anl.gov >>>>> <mailto:smar...@mcs.anl.gov>> wrote: >>>>> >>>>> Dear All, >>>>> >>>>> 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 >>>>> (https://tools.ietf.org/html/rfc2818#section-3.1 >>>>> <https://tools.ietf.org/html/rfc2818#section-3.1>), 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 >>>>> <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 Mar 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 >>>>> <http://secure-web.cisco.com/1CCWzya20RlAyAnWodonVq7GRuMGLiFiEkD5o0k2yX0mpK2s6kdNCTk8KkFJUemnkopGfriihYembpZRsQNLJ0AvyZouQiHv9UHW6S5BMbEbbwKA1dPFKxeMaMROveQCQucNLaAUlXO19u6HO4Y5VrOM-7wc3bE15ZkgEt6b99eXlWeHI-AmBXrWL8jvNsRxTN8SRkl3SS4-cdhSRn34Sz4XGA8aZ5b33JXjN_rc_TOaG4d3VabyWRbj9jfHAqYdQW0MP5S3xDPjXHUokSWxYXZfiU3eKCXA4DPtdFUqYtLUWDQaoUpJjOgXFAOKtggWo0JPuz76VgiP4WtUZSjBeHX8pOMxWfFWqk50_oUKstd8/http%3A%2F%2Fglobus.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). >>>>> >>>>> We have created a page where additional details about this change will >>>>> be communicated: >>>>> https://docs.globus.org/security-bulletins/2015-12-strict-mode/ >>>>> <https://secure-web.cisco.com/1bjBzv-ex3os8T9Ug5PhEDxWa6pGEAP32mYnqSSujsdtn-z6CZWQXo_yEsisVAkjX9fcjMNkYFCIszpPyZ2eq2AdQ195h8OBxkFkI2TNvJ7OULkl3YjX1BhIKteDjGAcLTLz0qCxErv6VHYhJ10WoMh3omD6r29JlcaSjJ91Qcz-aG-DSR0z69dwq6hWhjHpIvuvt5FplFEYdbHQoTbVriOs2YO2FOGzjVe-5SQ0GVpVLwch7I7yi1hOSFgLF-iO6BRIEADK20YV0K5bu8pme8Oc108nkI2MOn2byy1WBVkmkuISdOtV6SdZt7jUPL7ayevcB_cG6X1NhRORPCuUk1Y6NZzW2P-0kBi0raq-UJkQIZjOlAZD3eEhTQn8r3V5W/https%3A%2F%2Fdocs.globus.org%2Fsecurity-bulletins%2F2015-12-strict-mode%2F> >>>>> The above page includes common reasons for incompatibilities and how to >>>>> check for compatibility. >>>>> >>>>> If you have any questions or concerns regarding this planned change, >>>>> please contact us at supp...@globus.org <mailto:supp...@globus.org>. >>>>> >>>>> - The Globus team >>> >> >
