是否有可能让 node.js https.request(客户端)与远程服务器协商任何可能的协议(protocol)(即使不安全)？我了解安全风险，但对于我的项目，某些网站仅适用于较旧/不安全的 SSL 协议(protocol)和密码。
例如:https://www.dot.ny.gov 不适用于(超时)curl 或最新的 node.js 7.10.1 默认配置在 Ubuntu 服务器 16.04 上。它仅适用于使用 --tlsv1.0 或 --sslv3 选项的 curl。
那么有没有办法让 node.js 使用一系列协议(protocol)(从最安全到最不安全)重新协商 SSL 连接，或者使用尽可能广泛的配置(通过 node.js 或底层 OpenSSL)来启用所有SSL 协议(protocol)和密码？
最佳答案
仅仅允许这些协议(protocol)并不能解决您描述的网站问题。 TLS 在设计上主要是向后兼容的，即如果遇到来自支持 TLS 1.2 的客户端的 ClientHello，则只能执行 SSL 3.0 或 TLS 1.0 的正确实现的服务器将仅使用支持的最佳协议(protocol)进行回复。这是因为客户端只是宣布它可以提供的最佳版本，然后服务器选择它支持的最佳版本，该版本等于或小于客户端提供的版本。只有这样“允许”才会生效，即如果客户端接受服务器的低版本回复。
但这不是您显示的网站的问题。在这种情况下，服务器或它前面的某个中间件有一个有问题的 SSL/TLS 堆栈，它只会在意外的 ClientHello 上发出声音。这些可能是 ClientHello，它具有意外的 TLS 版本、意外的扩展、意外的密码、太小或太大或类似的特性。
在这种特定情况下，TLS 协议(protocol)版本似乎根本不是问题，但它看起来更像是 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 .
关于node.js - 允许 node.js HTTPS 请求的所有 SSL 协议(protocol)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46067957/