允许所有SSL协议用于node.js HTTPS请求

Question

是否有可能使node.js https.request（客户端）与远程服务器协商任何可能的协议（即使不安全）？我了解安全风险，但对于我的项目，一些网站只能使用较旧/不安全的SSL协议&密码。

例如：https://www.dot.ny.gov与curl或最新的node.js 7.10.1 Ubuntu Server 16.04上的默认配置不起作用（超时）。它仅适用于curl，使用--tlsv1.0或--sslv3选项。

那么有没有办法让node.js使用一系列协议（从最安全到最不安全）重新协商SSL连接，或者使用尽可能最广泛的配置（通过node.js或底层OpenSSL）启用所有SSL协议&密码？

Answer 1

用于制作HTTP（S）请求的最流行的NPM软件包之一是request。 根据其文档，您可以指定要接受的SSL协议。

如果您事先知道要访问的网站以及他们使用的协议，可以根据请求设置它。否则，我想你可以写一些条件，虽然做多个请求的开销会很麻烦。

Answer 2

只要允许这些协议不会解决您在网站上描述的问题。 TLS在设计上主要是向后兼容的，即只有在SSL 3.0或TLS 1.0的适当实施的服务器才会以支持TLS 1.2的客户端的ClientHello所支持的最佳协议进行回复。这是因为客户端只是宣布它可以做的最好的版本，然后服务器会选择它支持的最好的版本，它等于或小于客户端提供的版本。只有当“允许”到位时，即，如果客户端将接受具有较低版本的服务器的答复。

但是，这不是您显示的网站的问题。在这种情况下，服务器或者它前面的一些中间盒有一个错误的SSL/TLS堆栈，它只是在意想不到的ClientHello上发出嘘声。这些可能是ClientHello，它具有意想不到的TLS版本，意外的扩展，意外的密码，这些密码太小或太大或类似的特性。

在这种特定情况下，TLS协议版本似乎并不是问题，但它看起来更像是ClientHello的大小是一个问题，也许是因为在它前面有一个旧的F5负载均衡器，其中this bug。由于浏览器往往只提供少量密码，因此它们的ClientHello最小，不会受到此问题的影响。例如，如果尝试使用如openssl s_client -connect www.dot.ny.gov:443 -cipher 'AES128-SHA'中减少的密码集，即使使用TLS 1.2 ClientHello，您也可以成功，但如果尝试更大的密码（例如-cipher 'AES'），它只会挂起而没有得到响应，可能是因为负载均衡器破损在大型ClientHello上。通过在命令行中强制执行TLS 1.0，您只需确保它不提供新的TLS 1.2密码，这也减少了ClientHello的大小。

有没有通用的方法来处理这种破碎的服务器，只是允许一切，因为“允许”的部分只是在服务器回复后（它不在这种情况下）出现，有些实际上可能会导致更多的问题服务器（例如提供太多的密码，这会增加ClientHello的大小）。相反，人们必须调试问题，找出破碎的服务器喜欢什么和讨厌什么，然后设计特定的TLS握手（版本，密码，扩展，大小...），以便服务器喜欢它。查找特定服务器接受的一种好方法是查看analysis by SSLLabs。