當我將我的伺服器版本（NGINX 1.16.0）和OpenSSL版本（1.0.2k）輸入到Mozilla SSL 設定產生器我得到了一長串 SSL 密碼。
例如，
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
然而當我訪問時密碼列表它只為 Nginx 提供兩個 SSL 密碼。
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
可用密碼較少是否會降低或損害安全性？如果我向客戶提供較少的密碼選項，是否會提高效能或調整其他一些重要特徵？
答案1
TLS（以及先前的 SSL）的允許之一是，伺服器和用戶端可以（並且通常必須）協商並同意啟動安全連線時相互支援的密碼。
這樣做的原因主要是為了相容性：它允許逐步引入新密碼，而不是破壞尚不支援該新密碼的客戶端和伺服器之間的連線。
這就是只使用一個密碼而不進行協商時會發生的情況。然後，當一方決定放棄舊密碼並升級到新密碼時，他們在不與其他方協調的情況下這樣做，連線就會中斷。在單一組織中，協調伺服器和客戶端的同時升級已經是一件相當麻煩的事情，儘管這是可能的，但在整個互聯網上，這樣的大爆炸升級當然幾乎是不可能的。
因此：密碼協商是好的。 （至少為了相容性。）
可用密碼較少是否會降低或損害安全性？
不。密碼數量並不能決定安全性。
密碼本身提供了安全性。
儘管某些密碼比其他密碼相對更安全（不同的演算法或相同的演算法具有更長的金鑰長度並且能夠提供前向安全可以使某些人比其他人更安全）而另一些人則很弱甚至被破壞，僅支援少數而不是所有滿足您的安全要求的密碼不會帶來額外的安全優勢。
（需要注意的是，您支援的每個密碼也需要在軟體中實現。因此更多的密碼==更多的程式碼==增加了錯誤和實現錯誤的可能性...）
如果我向客戶提供較少的密碼選項，是否會提高效能或調整其他一些重要特徵？
不，儘管不同的密碼將具有顯著不同的效能統計資料和不同的用例，但除了上面關於更少的密碼意味著更少的程式碼和更低的零日漏洞利用風險的警告之外，這密碼數量你支援伺服器端不會影響效能以任何相關方式。僅支援少數而不是全部滿足安全要求的密碼不會帶來額外的效能優勢。
支援的密碼越少意味著相容性越差。（因為您通常將伺服器限制為最新和最強的密碼，而舊客戶端可能不支援這些密碼和/或對它們來說計算成本可能太高。）
記錄用戶代理字串並盤點更新更新後的影響。SSL 實驗室的使用者代理功能 預先。