Java 客户端中带有 SNI 的 TLS

Question

关于security and trust working group for NHIN Directregarding the IP-to-domain mapping problem that is created with traditional SSL 的讨论正在进行中。如果 HISP（由 NHIN Direct 定义）想要为提供商托管数千个 NHIN Direct“健康域”，那么必须为每个域购买 IP 将是“人为夸大的成本”。

由于 Apache 和 OpenSSL 最近发布了支持 SNI 扩展的 TLS，因此可以在服务器端使用 SNI 作为此问题的解决方案。但是，如果我们决定允许 NHINDirect 传输层的服务器实现支持 TLS+SNI，那么我们必须要求所有客户端也支持 SNI。默认情况下，基于 OpenSSL 的客户端应该执行此操作，如果您给定的编程语言 SSL 实现不支持 SNI，我们总是可以通过 stunnel 实现一个支持 TLS+SNI 的客户端来代理。使用 OpenJDK 的本机 Java 应用程序似乎还不支持 SNI，但我无法从该项目中得到直接的答案。我知道有可用的 OpenSSL Java 库，但我不知道这是否可行。

您能否给我一个“最先进的”总结，说明 TLS+SNI 对 Java 客户端的支持在哪里？我需要一个 Java 实现者的观点。

Answer 1

JavaSE 7 在 JSSE 中支持 SNI。

http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html

注意，它似乎有问题，您可以在此处阅读：

SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0

Answer 2

还可以对原始 Sun JDK (bootclasspath) 的某些行进行修补以使服务器 SNI 正常工作。

类：sun.security.ssl.ServerHandshaker

添加字段

    /** Use for SNI */
    private ServerNameExtension serverNameExtension = null;

Patch Method clientHello（添加这些行）

    /* Use for SNI */
    this.serverNameExtension = (ServerNameExtension)mesg.extensions.get(ExtensionType.EXT_SERVER_NAME);

补丁方法 setupPrivateKeyAndChain（更改）

    if (this.conn != null) { alias = km.chooseServerAlias(algorithm      , null, this.conn);
    } else                 { alias = km.chooseEngineServerAlias(algorithm, null, this.engine); }

to

    final Principal[] principals = (this.serverNameExtension == null) ? null : this.serverNameExtension.getHostnamePrincipals();
    if (this.conn != null) { alias = km.chooseServerAlias(algorithm      , principals, this.conn);
    } else                 { alias = km.chooseEngineServerAlias(algorithm, principals, this.engine); }

添加到类 sun.security.ssl.ServerNameExtension

static final class ServerNamePrincipal implements Principal {
    private final String name;
    ServerNamePrincipal(final String name) { this.name = name; }
    @Override public String getName() { return this.name; }
    @Override public String toString() { return this.name; }
}

public Principal[] getHostnamePrincipals() {
    final List<Principal> principals = new LinkedList<>();
    for(final ServerName name : this.names) {
        if(name.type == NAME_HOST_NAME) { principals.add(new ServerNamePrincipal(name.hostname)); }
    }
    return principals.toArray(new Principal[principals.size()]);
}

Answer 3

我正在和 ftrotter 做同一个项目。

请注意支持 数千 个域的要求。我不认为 SAN 会削减芥末，原因有两个。首先，证书的大小将变得巨大，这可能至少会导致性能问题。其次，这些域名会频繁地来来去去，尤其是在 NHIN Direct 的早​​期。每次域进出时都必须更新证书的操作负担将是不可接受的，恕我直言。

应 ftrotter 的要求，我在谷歌上搜索了一些关于 java、TLS 和 SNI 的主题，以及其他实现相当于基于命名的虚拟主机情况的方法，每个虚拟主机都有一个证书。这是我想出的：

• JSSE（Java 安全套接字扩展）支持 TLS，并且对 TLS+SNI 有“部分支持”。我不知道在这种情况下部分支持意味着什么。我看到的评论表明，现有的支持不足以进行基于命名的虚拟主机，这基本上是我们所需要的。

• 我发现一篇文章声称 JSSE 的 JDK7 版本将支持 TLS+SNI（日期为 2008 年 11 月 20 日），我发现一篇声称它赢了't（日期为 2009 年 2 月 27 日）。两者都不是特别权威。

• 早在 2009 年 2 月至 3 月，一些从事 OpenJDK 7 工作的人讨论了有关向 JSSE 添加 SNI 支持的问题，包括发布源补丁。 （线程从这里开始： http://www.mail-archive.com/security-dev@openjdk.java.net/msg00612.html)。 OpenJDK7 不会在 2010 年 9 月之前发布。我不知道 Java 7 平台什么时候发布。

• java.sun.com 上根本没有什么实质性的东西，所以我真的完全不知道 Sun 的计划是什么。

• 显然有一种不同的方式来完成基于名称的虚拟主机，这显然是广泛兼容的，使用每个托管服务器的单个证书，其中包含多个通用名称和多个主题替代名称。见http://wiki.cacert.org/VhostTaskForce和Serve different certs for same Tomcat application via connectors?

如果您有很多虚拟主机，这种方法会创建非常大的证书（由于所有这些 CN 和 SAN）。 NHIN Direct 最近的面对面会议中的一位成员谈到希望支持 数以千计 的虚拟主机。我的猜测是这会破坏很多实现。此外，每次添加或删除虚拟主机时都必须更新证书，这听起来像是一种荒谬的操作负担。

总而言之，对于每个虚拟主机具有单独证书的基于名称的虚拟主机的当前 Java 技术状态似乎是“不能做”。此外，尚不清楚何时或是否会添加。

有人同意还是不同意？有谁知道 OpenJDK 项目是否有意“向后移植”对 Java 6 的 SNI 支持？