[Gt-eos] gsissh trusting DNS by default instead of usual rule

[Mischa Salle]

On Wed, May 15, 2019 at 11:17:01PM +0000, Dave Dykstra wrote:
> On Tue, May 14, 2019 at 12:41:05PM +0200, Mischa Salle wrote:
> > On Mon, May 13, 2019 at 03:19:18PM +0000, End of Support of Globus Toolkit wrote:
> ...
> > > I recently noticed that gsissh (from gsi-openssh-7.4p1-2.3.osg34.el7)
> > > does not by default enforce that the expected host name matches the host
> > > certificate or one of its SANs as is the normal rule for https
> > > connections.  Instead, it also accepts a DNS alias, unless one sets the
> > > ssh config option "GSSAPITrustDNS no".  Trusting the DNS by default
> > > seems to me to be quite a security flaw, and defeats one of the primary
> > > purposes of X.509 verification.  Could this default be changed?
> > There seem to be two separate issues here. First of all, according to man
> > 7 ssh_config:
> >      GSSAPITrustDns
> > 	 Set to "yes" to indicate that the DNS is trusted to securely
> > 	 canonicalize the name of the host being connected to. If "no",
> > 	 the hostname entered on the command line will be passed
> > 	 untouched to the GSS- API library.  The default is "no".
> > so if I understand correctly the current default setting for gsi-openssh
> > would be to skip hostname verification altogether, so no gridcf-based
> > library would be involved. I agree I'm puzzled why this is the default
> > setting?
> 
> The man page may say the default is no, but apparently the default is
> actually yes.  In fact the comment in /etc/gsissh/ssh_config showing
> the default values says
> 	#   GSSAPITrustDNS yes

Ah sorry, I was very confusing there. I quoted from the (standard)
manpage for openssh since the option itself is not specific for the GSI,
and I wanted to give the description of the option. I should have
removed the default (or quote from the gsi-openssh-clients manpage
(gsissh_config) instead which indeed does state that there the default
is yes). By the way, that default long-predates the change in the globus
libraries.

> Actually even when set to "yes" it does verify that the host certificate
> name (or SAN) matches the DNS alias, so it doesn't completely skip
> hostname verification.  But it's not worth a whole lot since the DNS
> isn't secured.

Just to make clear, you mean it uses something like the old-style (and
insecure) globus behaviour:
- user requests host X
- server resolves X to IP Y
- server reverse resolves Y to Z
- server checks Z appears in the hostcert (for Globus that always had to
  be the CN field, here it seems it could also be SANs)
while the proper check is to verify that X already appears in the
hostcert.

> > The second point relates to the globus libraries themselves, further
> > below.
> > 
> > > After googling around about this, I found some indication that this
> > > might be related to a more general issue with the Globus Toolkit, but I
> > > haven't checked any other tools.
> > I think this has been changed a few years ago, see also
> > https://docs.globus.org/security/security-bulletins/2015-12-strict-mode/
> 
> Yes I think that's what I was thinking about.  At a rough reading it
> seems to apply, but as I recall when globus turned this on everybody
> just had to make sure that the host name was not only listed in the
> Common Name but was also in the Subject Alternative Name.  I don't think
> that even the behavior prior to strict mode allowed using DNS aliases
> the way GSSAPITrustDNS does.
no, indeed. The old style globus would only verify the CN field, and had
no support for SANs. I think they changed both at the same time, because
the reverse DNS lookup was essentially to workaround the problem of
lacking SAN support as far as I know.

Mischa

> 
> > I think probably the default needs changing back to 'no' and then it
> > hopefully 'just works'.
> 
> Yes I think so.
> 
> Dave

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4521 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20190516/a5c0f7e4/attachment.p7s>