这在 Java 中是不切实际的。它需要修改 JSSE 实现或插入替代方案。
我最终通过部署 How's My SSL 并使用客户端的跨域 AJAX 检查 SSL 状态并将其报告给我的应用服务器来解决此问题。
您需要有来自客户端的未经代理的直接请求,才能正确评估其 SSL 的状态。不要在 How's My SSL 前面放置 HTTPS 负载平衡器。它会破坏它并给你不正确的结果。
这是一个客户端 JavaScript 的 sn-p,应该可以使用公共的 How's My SSL 服务(我建议部署您自己的):
$.getJson('https://www.howsmyssl.com/a/check')
.done(function (result) {
$.post('/logs', {
name: 'howsmyssl',
level: 'info',
message: result
});
})
.fail(function(err) {
$.post('/logs', {
name: 'howsmyssl',
level: 'error',
message: 'could not reach howsmyssl'
});
});
您需要在您的应用服务器上的 /logs 上运行一个 REST 端点,该端点可以接收 POST 来捕获它。您可以随心所欲地更改该路径和消息的格式。此端点应经过身份验证,并应使用事件时间、经过身份验证的主体(用户)以及可能的其他信息(如 IP 地址)来丰富日志。
结果的内容是这样的(为了便于阅读,印刷得很漂亮):
{
"given_cipher_suites": [
"TLS_GREASE_IS_THE_WORD_8A",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_RSA_WITH_AES_128_GCM_SHA256",
"TLS_RSA_WITH_AES_256_GCM_SHA384",
"TLS_RSA_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_AES_256_CBC_SHA",
"TLS_RSA_WITH_3DES_EDE_CBC_SHA"
],
"ephemeral_keys_supported": true,
"session_ticket_supported": true,
"tls_compression_supported": false,
"unknown_cipher_suite_supported": false,
"beast_vuln": false,
"able_to_detect_n_minus_one_splitting": false,
"insecure_cipher_suites": {
},
"tls_version": "TLS 1.2",
"rating": "Probably Okay"
}
您可以将其记录到日志聚合器或数据库中,以便稍后查询以查找要致电或发送电子邮件的特定用户。您甚至可以提醒用户您的应用中浏览器的 TLS 存在漏洞,并特别强调即将到来的 TLS 1.2 截止日期以及他们可以采取哪些步骤来更新浏览器以进行补偿。