java 1.6 TLS1.2 支持使用代理 nginx/squid 解决问题

Question

我有一个旧版 Java Web 应用程序，它调用外部 Web 服务。该服务的提供者正在关闭 TLS1.0 支持。所以，我想看看应用程序如何继续与服务一起工作。

我看到的选项是 a) 使用 BouncyCaSTLe JCE 而不是 Java JCE http://boredwookie.net/index.php/blog/how-to-use-bouncy-castle-lightweight-api-s-tlsclient/ ，我猜这需要代码更改/重新编译(我们没有这样做的奢侈)或2)使用代理服务器https://www.reddit.com/r/sysadmin/comments/48gzbi/proxy_solution_to_bump_tls_10_connection_to_tls_12/

我已经尝试过 nginx 代理 - 它似乎无法处理终端服务器期望的 TLS1.0 传入和 TLS1.2 之间的切换。

 server { listen 443 ssl; server_name proxy.mydomain.com;

ssl_certificate D:/apps/openssl/proxy.mydomain.com.cert;
ssl_certificate_key D:/apps/openssl/proxy.mydomain.com.private;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2；
ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES -CBC3-SHA:!SRP;
ssl_prefer_server_ciphers 开启；

地点/{
proxy_pass https://fancyssl.hboeck.de/ ;
}

自 https://fancyssl.hboeck.de 以来，此操作失败并出现 502/错误网关错误仅支持 TLS1.2 但适用于 https://www.google.com支持 TLS1.0。

我在 Windows 上这样做。

Answer 1

这不是 TLSv1.2，它缺少 SNI 导致重新协商。

首先，我使用与您类似的配置设置 nginx(1.8.1/Windows)，除了使用我自己的 key 和证书并代理到我自己的测试服务器。它工作正常，使用 TLSv1.0 从 Java6 请求者连接到使用 TLSv1.2(甚至 ECDHE-RSA-AES256GCM-SHA384，“最佳”密码套件之一)的服务器，并且返回页面也很好。我试过fancyssl.hboek.de和你一样得到502。

使用wireshark，我看到nginx不发送SNI(默认情况下)并且至少使用IPv4地址46.4.40.249(我没有IPv6)该服务器显然托管多个域，因为没有SNI它提供了不同的(并且已过期!) 证书，用于 *.schokokeks.org ，并在第一个应用程序数据(请求)之后发送加密握手(重新协商请求 - nginx 不支持)。使用 openssl s_client 进行测试确认有 SNI 的服务器立即发送页面，但没有它的服务器首先重新协商；将 nginx 重新指向 openssl s_server确认如果服务器请求重新协商，没有收到响应，然后关闭 nginx 将其视为 502。

我猜想 Apache 正在重新协商，因为它意识到请求的主机不在证书范围内——除了它再次使用了“错误”的证书。我没有试图追踪那部分。

当我连接时，Google 确实支持 TLSv1.2(和 ECDHE-RSA-AESGCM)，但即使没有 SNI 也不会重新协商，大概是因为它的容量如此之大，没有其他东西可以在 www.google.com 上运行服务器，没有歧义。我的测试服务器没有虚拟主机，所以不需要 SNI。

The nginx documentation reveals a directive proxy_ssl_server_name 可以设置on启用 SNI，然后代理到该服务器即可。

仅供引用:该网页上的一些陈述是错误的，尽管它的结论(如果可能的话使用 TLSv1.2 与 ECDHE 或 DHE 和 AES-GCM)是好的。
此外，您的大部分 ssl_ciphers string 没用，但你没有问这个。

ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP

HIGH是一个很好的开始。
SEED在 Java/JSSE 客户端(仅)使用的服务器中是无用的，因为它不是在 Java 端实现的。即使在 Java 之外，它也几乎只在韩国使用，在那里它被创建为 DES 或 IDEA 的替代品，即使在那里，它也大多被作为 AES 替代品的 ARIA 淘汰——但 OpenSSL 并没有实现它和因此 nginx。
aNULL可能不需要，因为 JSSE 默认禁用“匿名”套件，但在这里作为深度防御是值得的。
!eNULL什么也没做; HIGH 中没有 eNULL 套件, 或 DEFAULT , 甚至 ALL .您只能通过显式或奇怪的 COMPLEMENTOFALL 获得它们。 ——你不应该这样做。
!EXPORT !DES !RC4没做什么;他们都不在 HIGH .相反，如果您从 DEFAULT 开始在旧版本的 OpenSSL 上，或来自 ALL ，那么他们会很好。
!PSK不需要； nginx 似乎没有为 PSK 配置，JSSE 也没有实现它。
!RSAPSK被忽略是因为 OpenSSL 没有实现该 key 交换，并且如果它实现了这些套件，则如上所述。
!aDH !aECDH被 !aNULL 覆盖因此什么也不做。
!EDH-DSS-DES-CBC3-SHA很傻；当您保留其他 DHE_DSS 和 3DES 套件时，没有理由排除这一套件。
!KRB5-DES-CBC3-SHA被忽略是因为 OpenSSL 没有实现 Kerberos，如果它实现了 nginx 就不会为它配置，而且在保留类似的同时排除一个套件是愚蠢的。
!SRP不需要；像 PSK nginx 显然没有配置和 JSSE 没有实现。

所以: HIGH:!aNULL是你所需要的全部。