伺服器配置 - 如果包含的 SSL 密碼選項太少，安全性是否會降低或受損？
當我將伺服器版本 (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;但是，當我訪問Cipherli.st時，它只為 Nginx 提供了兩個 SSL 密碼。
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;擁有更少的可用密碼會降低或損害安全性嗎？如果我向客戶提供更少的密碼選項，它會提高性能還是調整其他一些重要特徵？
TLS（以及之前的 SSL）中的一項允許是伺服器和客戶端可以（並且通常必須）協商並同意在啟動安全連接時它們相互支持的密碼。
這樣做的原因主要是為了兼容性：它允許逐步引入新密碼，而不是破壞尚不支持該新密碼的客戶端和伺服器之間的連接。
這就是在沒有協商的情況下只使用一個密碼時會發生的情況。然後，當一方決定放棄舊密碼併升級到新密碼時，他們在沒有與其他方協調的情況下這樣做，連接中斷。在單個組織中，協調同時升級伺服器和客戶端已經是一件很麻煩的事，儘管有可能，但在整個網際網路上，這樣的大爆炸式升級當然幾乎是不可能的。
因此：密碼協商是好的。（至少為了兼容性。）
擁有更少的可用密碼會降低或損害安全性嗎？
不可以。密碼的數量並不能決定安全性。
提供安全性的是密碼本身。
儘管有些密碼比其他密碼相對更安全（不同的算法或具有更長密鑰長度的相同算法以及提供前向安全性的能力可以使一些密碼比其他密碼更安全）並且其他密碼較弱甚至被破壞，但在僅支持少數而不是全部滿足您的安全要求的密碼。
（有一點需要注意的是，您支持的每個密碼也需要在軟體中實現。因此更多的密碼 == 更多的程式碼 == 增加錯誤和實現錯誤的可能性……）
如果我向客戶提供更少的密碼選項，它會提高性能還是調整其他一些重要特徵？
不，儘管不同的密碼會有顯著不同的性能統計數據和不同的案例，除了上面關於更少密碼意味著更少的程式碼和更低的零日攻擊風險的警告之外，你支持伺服器端**的密碼數量確實不會以任何相關方式影響性能。僅支持少數而不是全部滿足您的安全要求的密碼並沒有額外的性能優勢。
支持的密碼越少意味著兼容性越差。（因為您通常將伺服器限制為較舊的客戶端可能不支持和/或計算成本太高的最新和最強密碼。）
記錄使用者代理字元串並盤點更新您的通過 事先參考諸如SSL Lab 的使用者代理功能之類的表來設置 Web 伺服器的安全性。