HTTPS 证书切换是如何工作的（就像在suche.org 上一样）？

Question

对于那些不知道 Suche.org 是什么的人来说，它是一个在 SSL 实验室的每个类别中都获得完美 A+ 评级的网站：（Suche.org SSL 实验室结果）。当我打开另一张关于ECC 证书在 Chrome 中不起作用的票时，我意识到了这个网站，其中一个响应者以该网站为例。

让我感到困惑的是，虽然Protocol Support报告的部分说该网站仅使用 TLSv1.2 ......

TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3   No
SSL 2   No

显然情况并非如此，因为在该Handshake Simulation部分下，它显示一些模拟的旧客户端正在使用 TLSv1.0 进行连接......

Android 4.0.4   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.1.1   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.2.2   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.3     EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDH secp521r1  FS

这有点令人沮丧，因为如果我像这样在测试网站上禁用 TLSv1.0...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

在我的测试网站上运行 SSL Labs 扫描会为一些旧客户端产生以下结果：

Android 4.0.4   Server closed connection
Android 4.1.1   Server closed connection
Android 4.2.2   Server closed connection
Android 4.3     Server closed connection
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

怎么可能同时只允许 TLSv1.2 连接，同时也支持旧客户端？

Answer 1

我很确定他们正在检查客户端功能并采取相应的行动，如@Jeff 的回答中链接的线程中所述。

要了解它的详细情况，请查看此。它显示了HAProxy根据不同客户的能力为不同客户提供不同证书的实现。我做了一个完整的复制/粘贴，以防止链接腐烂，因为我认为这个问题将来可能会引起人们的兴趣：

SHA-1 证书即将淘汰，您应该尽快升级到 SHA-256 证书……除非您有非常老的客户端并且必须暂时保持 SHA-1 兼容性。

如果您处于这种情况，您需要强制您的客户端升级（困难）或实施某种形式的证书选择逻辑：我们称之为“证书切换”。

最具确定性的选择方法是向提供 TLS1.2 CLIENT HELLO 的客户端提供 SHA-256 证书，该客户端在 signature_algorithms 扩展中明确声明他们对 SHA256-RSA (0x0401) 的支持。

现代网络浏览器将发送此扩展。但是，我不知道目前有任何开源负载均衡器能够检查 signature_algorithms 扩展的内容。将来可能会出现，但目前实现证书切换的最简单方法是使用 HAProxy SNI ACL：如果客户端提供 SNI 扩展，则将其定向到提供 SHA-256 证书的后端。如果它没有提供扩展，假设它是一个使用 SSLv3 或某些损坏版本的 TLS 的旧客户端，并提供一个 SHA-1 证书。

这可以通过链接前端和后端在 HAProxy 中实现：

global
        ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128
-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-R
SA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

frontend https-in
        bind 0.0.0.0:443
        mode tcp
        tcp-request inspect-delay 5s
        tcp-request content accept if { req_ssl_hello_type 1 }
        use_backend jve_https if { req.ssl_sni -i jve.linuxwall.info }

        # fallback to backward compatible sha1
        default_backend jve_https_sha1

backend jve_https
        mode tcp
        server jve_https 127.0.0.1:1665
frontend jve_https
        bind 127.0.0.1:1665 ssl no-sslv3 no-tlsv10 crt /etc/haproxy/certs/jve_sha256.pem tfo
        mode http
        option forwardfor
        use_backend jve

backend jve_https_sha1
        mode tcp
        server jve_https 127.0.0.1:1667
frontend jve_https_sha1
        bind 127.0.0.1:1667 ssl crt /etc/haproxy/certs/jve_sha1.pem tfo ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
        mode http
        option forwardfor
        use_backend jve

backend jve
        rspadd Strict-Transport-Security:\ max-age=15768000
        server jve 172.16.0.6:80 maxconn 128

上面的配置在名为“https-in”的前端接收入站流量。该前端处于 TCP 模式并检查来自客户端的 CLIENT HELLO 以获取 SNI 扩展的值。如果该值存在并且与我们的目标站点匹配，它会将连接发送到名为“jve_https”的后端，后者重定向到一个也名为“jve_https”的前端，在该前端配置 SHA256 证书并将其提供给客户端。

如果客户端未能提供带有 SNI 的 CLIENT HELLO，或者提供与我们的目标站点不匹配的 SNI，它会被重定向到“https_jve_sha1”后端，然后到其相应的前端，在那里提供 SHA1 证书。该前端还支持较旧的密码套件以容纳较旧的客户端。

两个前端最终都重定向到一个名为“jve”的后端，该后端将流量发送到目标 Web 服务器。

这是一个非常简单的配置，最终可以使用更好的 ACL 进行改进（HAproxy 定期添加新的 ACL），但是对于基本的证书切换配置，它可以完成工作！

Answer 2

在https://community.qualys.com/thread/16387提出了类似的问题

我认为这个答案是解决方案：

suche.org 是一个聪明的实现。据我所知，它会询问客户的能力，然后只提供最好的，以消除任何疑问。