允許所有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。