避免在 TLS 客户端中发送TLS_EMPTY_RENEGOTIATION_INFO_SCSV密码 你好

Avoid sending TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher in TLS Client Hello

本文关键字：TLS RENEGOTIATION EMPTY INFO SCSV 你好 密码 客户端      更新时间：2023-09-26

Node.js默认发送TLS_EMPTY_RENEGOTIATION_INFO_SCSV密码以保护自己免受POODLE攻击。

我试图通过使用自定义密码列表覆盖 TLS 密码来避免发送此密码(即使这可能会带来安全风险(。

但是，无论我做什么，Node.js都会发送TLS_EMPTY_RENEGOTIATION_INFO_SCSV密码。我试图故意避免发送此密码来模仿Firefox/Chrome的TLS协商。

以下是我用来修改和检查 Node 发送的密码的代码：

var request = require('request');
var ciphers = [
    'ECDHE-ECDSA-AES128-GCM-SHA256',
    'ECDHE-RSA-AES128-GCM-SHA256',
    'ECDHE-ECDSA-AES256-SHA',
    'ECDHE-ECDSA-AES128-SHA',
    'ECDHE-RSA-AES128-SHA',
    'ECDHE-RSA-AES256-SHA',
    'DHE-RSA-AES128-SHA',
    'DHE-RSA-AES256-SHA',
    'AES128-SHA',
    'AES256-SHA',
    'DES-CBC3-SHA'
].join(':');
var options = {
    ciphers: ciphers,
    secureProtocol: 'TLSv1_2_method',
    url: 'https://www.howsmyssl.com/a/check'
};
request(options, function (error, response, body){
    if (!error) {
        console.log(body);
    }
    else {
        console.log(error);
    }
});

有没有办法禁用在 Node.js 中发送此密码？

鉴于此问题与 Node.js 有关，有一种简单的方法可以处理您的问题，而无需实际深入研究：

将 Web 代理放在 Node.js 进程前面，让它处理完整的 SSL 连接。在 Node.js 代码本身中，您只会向本地 HTTP 服务器发送请求。

使用 nginx 的示例配置(在 http 指令内(：

server {
   listen 8080;
   location / {
      resolver 8.8.8.8;
      proxy_pass https://www.howsmyssl.com$uri$is_args&args;
      proxy_ssl_protocols TLSv1.2;
      proxy_ssl_ciphers AESGCM:!aNULL;
   }
}

并将 nodejs 更改为：

var request = require('request');
var options = {
    url: 'http://localhost:8080/a/check'
};
request(options, function (error, response, body){
    if (!error) {
        console.log(body);
    }
    else {
        console.log(error);
    }
});

不幸的是，尽管我实际上这样做了，结果是一样的：

{"given_cipher_suites":["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_DH_DSS_WITH_AES_256_GCM_SHA384","TLS_DHE_DSS_WITH_AES_256_GCM_SHA384","TLS_DH_RSA_WITH_AES_256_GCM_SHA384","TLS_DHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_DH_DSS_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256","TLS_DH_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_EMPTY_RENEGOTIATION_INFO_SCSV"],"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"}

这基本上意味着它可能是标准的OpenSSL行为。

有一些选项可以在OpenSSL中使用SSL_CTX_set_options

这里特别有趣的是安全重新协商部分和此选项：

SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION

允许 OpenSSL 与未修补的客户端或服务器之间旧的不安全重新协商。有关更多详细信息，请参阅安全重新协商部分。

我不确定这是否真的阻止了重新协商密码的发送。如果此选项确实正确，则可能有一种方法可以修补 Node.js以使用该选项或使用该选项重新编译 OpenSSL。

当然，也可以选择使用旧的未修补版本。据我了解，TLS_EMPTY_RENEGOTIATION_INFO_SCSV与贵宾犬无关，但来自较旧的修复程序：

CVE-2009-3555(OpenSSL 公告(2009 年 11 月 5 日：
实施RFC5746以解决 SSL/TLS 重新协商中的漏洞。在 OpenSSL 0.9.8m 中修复(受影响的

0.9.8l、0.9.8k、0.9.8j、0.9.8i、0.9.8h、0.9.8g、0.9.8f、0.9.8e、0.9.8d、0.9.8c、0.9.8b、0.9.8a、0.9.8a、0.9.8(

然而，Modern Node.js带有静态链接的OpenSSL，并且不支持OpenSSL 0.9.8，因此您需要旧版本的Node.js无论如何...或者将nginx的东西与未打补丁的OpenSSL一起使用......

这就是我陷入困境的地方。这不是一个完整的答案，但我认为它至少值得分享。

总而言之，我认为如果您想在不重新编译的情况下执行此操作，请使用带有未修补的 OpenSSL 的 nginx，并配置多个服务器，每个客户端一个要模仿。

如果你要求在节点中完成此操作，最好的办法是直接在那里修补OpenSSL并重新编译节点。

似乎

TLS_EMPTY_RENEGOTIATION_INFO是一个占位符密码套件，其功能与扩展"renegotiation_info"相同。此外，OpenSSL似乎没有办法设置"renegotiation_info"扩展名，并且需要这个空的密码套件。

来源： c-openssl-setting-list-of-ciphers
来源：RFC 5746 第 3.3 节

相关文章：