Bugzilla – Bug 1753
bug 318 resolution opens door to spoofing ?
Last modified: 2008-10-30 04:56:36
You need to
before you can comment on or make changes to this bug.
It seems the resolution to bug 318 has made spoofing easier:
Say the unsuspecting user does a globus-url-copy involving remote server
foo.good_guys.net. Now the reply to the DNS lookup is faked to point to
bar.bad_guys.org. With the old (Globus 2.2.4) behavior, the client code
expected to see a valid certificate for foo.good_guys.net, signed by an
accepted CA. This meant that the bad guys *also* needed to break into
foo.good_guys.net and copy the certificate. With the new code, though,
the client expects to see a valid certificate for bar.bad_guys.org, which
the bad guys can easily obtain. Am I missing something here?
You would need to trust the CA for the bad_guys.org certificate with positive
signing rights. Unless they have stolen the keys of a CA trusted by the client
and created a certificate thusly, I don't think this is a problem.
The certificate is still checked for validity against accepted CAs. This does
obviate a check for a strictly matching hostname (cert<->target). It also
brings g-u-c in line with most other Globus/grid tools in terms of service name
This is not to say it is the best method, or the worst. I feel it's an
appropriate amount of give and take, however, for the convenience it adds. Also
note that this is client-based, so developers can still write code that does
strict checking if they wish to.
> ------- Additional Comments From email@example.com 2004-05-25 11:16 -------
> You would need to trust the CA for the bad_guys.org certificate with positive
> signing rights. Unless they have stolen the keys of a CA trusted by the
> and created a certificate thusly, I don't think this is a problem.
The bad guys would have no problem obtaining a certificate from their
national CA, which may very well be in the list of CAs trusted by the
duped client (it can even be the same as that of the good guys).
> The certificate is still checked for validity against accepted CAs. This
> obviate a check for a strictly matching hostname (cert<->target). It also
> brings g-u-c in line with most other Globus/grid tools in terms of service
There ought to be a way to prevent the scenario I sketched earlier, while
still allowing for sensible alias resolution. Might the problem be solved
by separating host certificates from service certificates? If so, are there
any plans to make Globus ready for that?
> This is not to say it is the best method, or the worst. I feel it's an
> appropriate amount of give and take, however, for the convenience it adds.
> note that this is client-based, so developers can still write code that does
> strict checking if they wish to.
Yes, it is not a showstopper right now, but I think the problem *must* be
What about having more than one host certificate for a single machine?
(As far as I know, that's not currently possible.)
Suppose I have a machine called foo.good_guys.net, and I want users
to be able to refer to it by any of several names:
Currently, one of those (say, foo.good_guys.net) is going to be the
primary name (the result of a reverse lookup on the IP address), and
the host certificate has to refer to that name. With the resolution
for bug 318, DNS handles everything (which is much more convenient
for users) -- but a bad guy could hijack DNS and cause clients to
accept a certificate for bar.bad_guys.org.
If the machine has certificates for all 4 valid names, the client can
check for a certificate that matches the name given on its command
line, and needn't do the reverse lookup. The bad guy's machine
would have to have a host key for one of the valid names to be able
to hijack it.
(If a user on "buford.good_guys.net" refers to "foo", that needs to
resolve to "foo.good_guys.net" for certificate verification purposes.)
This would mean some extra work for the system's administrators
(generating extra host keys and keeping them in sync with the desired
DNS aliases). It would also mean backing out the resolution for
bug 318. Getting from here to there could be non-trivial.
The work for bug #6331 adds an environment variable to disable DNS lookups in
the GSI code, as well as code to handle certs which can have multiple DNS names
in subjectAltName extension. A similar implementation is planned for GSI Java.