java /SPNEGO : Unwanted SPN canonicalization?

Question

我目前正在尝试使用 SPNEGO library 将 Java 客户端实现到受 SPNEGO 保护的 Web 服务来自 SourceForge(服务器使用相同的库)。我无法让它成功验证，我的请求总是以

HTTP/1.1 500 Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

这类似于我从具有不适当主机名的浏览器访问 Web 服务时遇到的症状，实际上 Wireshark 中的一些调试显示客户端随请求发送了错误的 SPN - 我发送到 service -test.client.com，注册为 SPN，在 DNS 中有 A 记录，但在 Windows 域中注册为 server-1234.client.corp 。即使我将请求发送到 http://service-test.client.com(请参阅匹配的 Host header )，Java 请求票证的 SPN 是“内部” Windows 名称:

从 Chrome 或 IE 发送的相同内容具有匹配的 Host header 和 SPN:

由于在我的代码或 SPNEGO 库中没有发生这种转换，我推测它一定发生在 JRE 中。我一直在研究 JGSS 源代码，但它有点难以理解。谁能告诉我如何跳过此翻译并获得正确 SPN 的票证？

客户端代码:

SpnegoHttpURLConnection con = new SpnegoHttpURLConnection("spnego-client", user, password);
con.connect(new URL("http://service-test.client.com:8083/service"));
int rc = con.getResponseCode();
String msg = con.getResponseMessage();

Answer 1

以上评论总结:

重新检查您的 DNS。进行反向查找。大多数问题都是由错误的反向 DNS 条目引起的。

第 85 页 RFC2713可能会帮助你并检查RFC4120并搜索“佳能”。

当基于主机的服务的 SPN 使用 GSS-API 构建时，您必须使用目标机制规范化该名称。 RFC 说

When a reference to a name of this type is resolved, the "hostname" may (as an example implementation strategy) be canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters.

Kerberos 5 RFC 说:

server and when transmitted. Thus, for example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party.

Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). In an environment without secure name service, application authors MAY append a statically configured domain name to unqualified hostnames before passing the name to the security mechanisms, but they should do no more than that. Secure name service facilities, if available, might be trusted for hostname canonicalization, but such canonicalization by the client SHOULD NOT be required by KDC implementations.

Implementation note: Many current implementations do some degree of canonicalization of the provided service name, often using DNS even though it creates security problems. However, there is no consistency among implementations as to whether the service name is case folded to lowercase or whether reverse resolution is used. To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization.

看起来 GSS-API impls 可能会规范化，但如果 DNS 不受信任，Kerberos 不应这样做。所以这取决于。完成反向查找是很自然的。这就是 Kerberos 验证主机名的方式。如果您正在运行 DNS 循环，这实际上是至关重要的。否则它永远无法构建真正的 SPN。

虽然我真的很想在 Kerberos 邮件列表中使用它。这是一个非常有趣的观点。

我已经检查了 MIT Kerberos 实现并且有方法 krb5_sname_to_principal如果您检查 sn2princ.c 中的源代码，它实际上会执行此操作:

if (type == KRB5_NT_SRV_HST) {
        struct addrinfo *ai = NULL, hints;
        int err;
        char hnamebuf[NI_MAXHOST];

        /* Note that the old code would accept numeric addresses,
           and if the gethostbyaddr step could convert them to
           real hostnames, you could actually get reasonable
           results.  If the mapping failed, you'd get dotted
           triples as realm names.  *sigh*

           The latter has been fixed in hst_realm.c, but we should
           keep supporting numeric addresses if they do have
           hostnames associated.  */

        memset(&hints, 0, sizeof(hints));
        hints.ai_flags = AI_CANONNAME;
        err = getaddrinfo(hostname, 0, &hints, &ai);
        if (err) {
#ifdef DEBUG_REFERRALS
            printf("sname_to_princ: failed to canonicalize %s; using as-is", hostname);
#endif
        }
        remote_host = strdup((ai && ai->ai_canonname) ? ai->ai_canonname : hostname);
        if (!remote_host) {
            if(ai)
                freeaddrinfo(ai);
            return ENOMEM;
        }

        if ((!err) && maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) {
            /*
             * Do a reverse resolution to get the full name, just in
             * case there's some funny business going on.  If there
             * isn't an in-addr record, give up.
             */
            /* XXX: This is *so* bogus.  There are several cases where
               this won't get us the canonical name of the host, but
               this is what we've trained people to expect.  We'll
               probably fix it at some point, but let's try to
               preserve the current behavior and only shake things up
               once when it comes time to fix this lossage.  */
            err = getnameinfo(ai->ai_addr, ai->ai_addrlen,
                              hnamebuf, sizeof(hnamebuf), 0, 0, NI_NAMEREQD);
            freeaddrinfo(ai);
            if (err == 0) {
                free(remote_host);
                remote_host = strdup(hnamebuf);
                if (!remote_host)
                    return ENOMEM;
            }
        } else
            freeaddrinfo(ai);
    }

所以，我想我们必须通过邮件列表询问。